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ABSTRACT 


The recently completed integrated project by the Systems Engineering and 
Analysis Cohort 15 at NFS has devised a regional Maritime Theater Security Force to 
conduct Phase Zero operations based on a tasking from OPNAV N8F. The force’s airlift 
capability was identified as a critical component in the accomplishment of the missions 
and the required force structure was determined using a mix of mathematical and linear 
optimization modeling. 

The goal for this thesis is to develop a stochastic model using Discrete Event 
Simulation (DES) that can be employed to analyze the devised force structure’s airlift 
operation performance at the operational/tactical level to augment the analysis work 
performed under that project. The intent is to provide a more complete solution for any 
stakeholders who want to take the project further to the next level. 

The resulting model demonstrates the ability to measure the airlift operation 
performance and provide insights into the operation workflow efficiency. The 
experiments conducted support the earlier findings on the devised Phase Zero force’s 
ability to meet the most stringent mission requirements but suggested a different 
maximum airlift capability. 
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I. INTRODUCTION 

A. PROBLEM STATEMENT 

The recently completed integrated project by the Systems Engineering and 
Analysis Cohort 15 (herein referred to as Project SEA-15) [1] in June 2009 has 
recommended an alternative force structure for operating in a maritime environment 
during the initial phase of military operations known as Phase Zero. The Phase Zero 
operation is comprised of three primary missions: anti-smuggling, civil support, and 
information sharing. The force’s airlift capability was also found to be a critical factor in 
the accomplishment of the civil support mission. Two variants to the force structure were 
proposed; one based on current platforms only, and the other with the inclusion of future 
platforms that are deployable by 2020, using total procurement and operating costs of 
$1.5B (PY08 constant dollars) per annum. 

As part of the solution, the force structure required for airlift operation support 
was determined by using a mix of mathematical and linear optimization modeling to 
ensure that all critical requirements defined for the mission scenarios could be satisfied at 
the lowest cost. The modeling was done using high-level and static performance 
parameters that did not take into consideration the tactical operation factors in a dynamic 
operating environment. While the abstraction may be adequate to support front-end 
strategic level planning, it does not have the resolution to support a proper performance 
analysis for the recommended force structure at the operation/tactical level. Eor example, 
the optimization model has assumed unlimited landing spots and a logistics crew that can 
support the concurrent loading of airlift platforms using a fixed loading time. The 
missing details are particularly important in this case, as the airlift operations are meant 
to support disaster relief missions characterized by short notice, high-load demands with 
a compressed delivery schedule, where the task force’s real-time throughput performance 
matters. 
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It is, therefore, neeessary to provide a higher resolution model to augment the 
analysis work that has already been performed under the Projeet SEA-15 so that a more 
complete solution can be made available to any stakeholders who want to take the project 
to the next level. 

B. OBJECTIVES AND SCOPE 

The main goal for the thesis work is to develop a dynamic model using the 
Discrete Event Simulation (DES) that can be used to analyze the airlift operation 
performance of the naval force structure recommended by Project SEA-15 at the 
operational/tactical level. A data-driven model will be developed to mimic the airlift 
operation process with the key factors abstracted as user-definable parameters to facilitate 
the analysis work in different settings. 

With the appropriate input data, the model output can be used to validate the 
performance of recommended force structures under different scenario requirements and 
support sensitivity analysis to identify key areas that may limit or improve the force 
structure capabilities and effectiveness in a different operating environment. The model 
will help stakeholders answer the following questions: 


• Is the proposed force structure optimized or feasible as per the high-level 
static analysis suggested it might be? 

• What are the operating profiles for the proposed force structure, e.g., the 
duration to complete a mission, the number and the sequence of the sorties 
flown, etc.? 

• What are the lower level performance measures for the proposed force 
structures and how well are they being met under the different mission 
demands, including operational availability, utilization rate, etc.? 

• How will the proposed force structure capabilities and effectiveness be 
affected by the operation and logistics support constraints? Eor example. 
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what is the number of concurrent sorties that can be supported and the 
turnaround time between sorties under the possible constraints of limited 
landing/loading spots and logistics crew support? 

• What are the force structure’s capabilities and limitations beyond the 
current designed mission envelope? 

• Can the proposed force structure be modified to achieve better mission 
effectiveness without impacting the other Phase Zero operation support? 
If so, what are the possible alternative structures and associated strengths/ 
weaknesses? 

C. PROJECT SEA-15 OVERVIEW [1] 

1. Background 

Project SEA-15 was conducted under NPS’ System Engineering Analysis 
curriculum as a capstone project for the students to combine their learning, and as a team, 
solve a real world problem. Thirty-three students from the United States (U.S.), Israel 
and Singapore participated in the project over a six-month period. The tasking given to 
this cohort came from the Warfare Integration/Senior National Representative (OPNAV 
N8E), which was to devise a maritime force for Phase Zero mission deployable by year 
2020. Specifically: 

Design a system of systems to employ a regional Maritime Theater 
Security Force to conduct all maritime missions associated with Phase 
Zero operations. Consider current fleet structure and funded programs as 
the baseline system of systems to execute security and shaping missions in 
developing these concept of operations, then develop alternative fleet 
architectures for platforms, manning, command and control, 
communication, logistics and operational procedures to evaluate against 
the current program. A complete redesign of a naval force capable of 
executing phase 0 operations, employable by 2020, and using total 
procurement and operating costs of $1.5B (FY08 constant dollars) per 
annum, should be one of the alternatives. 
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2 . 


General Work 


The first thing that the team did was to develop a mission statement for the 
required maritime force. After much research on the various definitions for the term 
Phase Zero, and their relevance to the world’s current landscape, the team has decided on 
the following: 

A Phase Zero force will work closely with multinational, interagency and other 
partners to maintain or enhance stability, prevent or mitigate crises and set the 
conditions for access and responsive crisis intervention. 

Based on the mission statement, the team has identified the following 13 essential 
missions that they believe will collectively contribute to the overall accomplishment of 
the Phase Zero force: 

• Civil Support 

• Train the local defense force 

• Equip the local defense force 

• Build relations with foreign nations 

• Restore critical infrastructure 

• Anti-smuggling operations 

• Anti-terrorism operations 

• Anti-illegal fishing operations 

• Force protection against threats 

• Anti-piracy operations 

• Information sharing 

• Freedom of navigation 

• Non-combatant evacuation operations 
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Given that there were similarities in terms of how these missions would be 
executed, and the types and characteristics of platforms involved, the team was able to 
consolidate the missions into three key ones, namely information sharing, anti-smuggling 
and civil support, using a multidimensional scaling technique. Figure 1 is the generated 
perceptual map illustrating how the various missions were perceived to be similar to one 
another. They are represented by their physical proximities on the map, based on 
surveyed inputs from individuals across NFS, including members from Operations 
Research and Systems Engineering Departments, the Naval War College and subgroup 
leads within the project team. 



Chil: Provide Civil Suppport 
lufrn: Restore Critical 
Iiifiastnictiire 

1 1 _ Shliitel: Share Iiitelhgence 

with Partners 

Infr^^ EqiiipLcl: Support Equipping 

of Local Defense Forces 
TraiuLcl: Tram Local 

ZV Defense Forces 

BitildRel: Birild Relations 

' y ~ - ) M Fo " Local Govenmients 

1 " ^ ^ 

-1 SelfDef ^ 

V 

FON :> 

1 - 

^ Smug: Redirce Srnugglrng 

1 ' \ ATO: Condirct Anti-tenorisrn 

Operations 

’iraSt^r i Piracy: Combat Piracy 

J Fish: Preverrt Illegal Fishmg 

FOX: Enforce Freedom of 
Navigation 

Selfbef: Provide for Force 

Self Deferrse 

NFO: Conduct Non- 
combatant Evacuation 


Figure 1. Phase Zero Perception Map (from [1]) 


Based on these three primary missions, the formulation of the force structure was 
carried out in the following six phases: 

• Consolidate the background information required for modeling the force 
structure, covering studies on the threat environments, platform 
availability and capabilities, etc.. 
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• develop mission requirements and scenarios to allow for further analysis in 
identifying the critical attributes that will impact the accomplishment of 
these missions, 

• perform gap analysis on current forces used for Phase Zero type missions 
and develop lessons learned, 

• develop initial force structures that could meet the mission requirements at 
the various levels defined. For each level, two force structures are 
required, one based on current platforms in the U.S. inventory only and the 
other with future platforms deployable before 2020. 

• apply optimization to determine the lowest cost configuration and fine- 
tune the results as required to produce the final force structures, and 

• conduct a logistics requirement study to work out the overall capabilities 
and costs for each force structure and with that, recommend the one that is 
deemed most suited for the Phase Zero missions. 

Two mission scenarios were created to simulate the Civil Support and Anti¬ 
smuggling missions in the Latin American area of responsibility. Latin America was 
chosen because there was a rich archive detailing past Phase Zero type missions 
conducted there that would provide the necessary background information for the team to 
construct the mission scenarios. The other reason was that Latin America was one of the 
key areas where drug trafficking and humanitarian crises prevailed. 

The Anti-smuggling scenario was constructed using a barrier patrol concept to 
simulate an effort to quell drug smuggling along the western coast of Mexico. The 
aviation elements and the size and speed of intercept vessels were found to be the most 
important force attributes in identifying and interdicting drug smugglers in that area. The 
Civil Support scenario was modeled after the need to support the Latin American 
populace following a natural disaster based on three different levels of severity, and it 
was found that the forces’ shipboard cargo capacity and its airlift capacity were most 
crucial in accomplishing the missions. Information Sharing requirements were studied as 
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part of the two scenarios based on how it could be employed to support the two 
operations, and in both cases, a reliable and fast means for sharing information was found 
to be a force multiplier to the missions. 

Six force structures were generated and after going through the optimization, fine- 
tuning and logistics considerations, the one devised for the high-severity scenario with 
the inclusion of future platforms was eventually recommended as the force structure most 
suited for the Phase Zero missions. The recommended force structure is summarized in 
Table 1 and its amortized annual cost is estimated at $360M, which allows four such task 
forces to be deployed at different areas of responsibility (AOR) given the $1.5B annual 
budget. 


S/N 

Ship 

Organic Assets 

1. 

One JMSDF DDH class 
destroyer 

Seven CH-53K Sea Stallion helicopters and six RQ-8 
Firescout UAVs 

2. 

One LPD-17 San Antonio 
class amphibious assault 
support vessel 

Two SH-60S Seahawk helicopters, six RQ-8 UAVs 
and two M-80 Stiletto 

3. 

One Joint High Speed 
Vessel (JHSV) 

Nil 

4. 

One Visby class corvette 

Six RQ-8 Firescout UAVs 


Table 1. Recommended Force Structure For Phase Zero Mission 


The SH-60 version was not explicitly stated in the report [1] under the 
recommendation section but based on the quoted performance specifications and the 
references made in other sections of that report, it can be inferred to be SH-60S (or the 
equivalent MH-60s). 

The specific capabilities for the platforms in the recommended force structure are 
provided in the Appendix A. 
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D. RELATED WORK 


1. Related Work in Airlift Operation Modeling 

There were studies found involving the modeling of airlift operations but 
performed in a dissimilar context or using different tools/approaches with respect to this 
thesis work. They are summarized below: 

• Curtin [2] has analyzed the Sea Based Logistics (SBL) concept involving 
inter-ship and intra-ship movement of material in his thesis work. A DES- 
based software package known as ARENA was used to simulate the inter¬ 
ship process of transferring pallets of load from a supply ship to a EHD 
class amphibious ship using vertical replenishment (VETREP) with CH-46 
helicopters followed by the intra-ship movements of the pallets from the 
landing spots to the storage area using forklifts. The analysis focused on 
the operational impact due to the number and lift capacity of the aircraft 
used. The study concluded that increasing the aircraft lift capacity will 
significantly reduce the total cycle time, whereas having more aircraft only 
marginally reduced the cycle time. 

• Kang, Doerr, Bryan and Ameyugo [3] have looked into another aspect of 
the SBE concept, i.e., to provide replenishment and logistics support for a 
deployed force ashore through direct Ship-To-Objective Maneuver 
(STOM). A DES model was developed to assess the STOM operations 
using an EHD-class amphibious ship as a sea base supported by 12 MV-22 
Osprey airlift platforms to transfer pallets (of load), bladders (of water), 
fuel and personnel ashore over a 15-day mission. The simulation results 
indicated that the number and reliability of the aircraft, as well as the 
sustainment requirements for the force ashore, were the critical factors for 
mission success based on those scenarios set up for the study. 

• Granger, Krishnamurthy and Robinson [4], on the other hand, have 
conducted a macro level analysis on a global airlift network across wider 
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geographical locations involving intermediate airfields. Two stochastic 
models employing different techniques were developed to support the 
analysis work, and at same time, to compare the capabilities of the 
techniques used for such work. The first model was simulation based, 
developed using a commercial software package known as ProModel, 
while the second model employed a network approximation method and 
was built using another commercial software package known as MPX. 
The models mimicked the transfer of cargo from an Aerial Port of 
Embarkation (APOE) to the Aerial Port of Debarkation (APOD) with three 
intermediate airfield options as depicted in Eigure 2. Based on the 
experiment setting, the analysis has shown that increasing the variability of 
ground times would correspondingly increase the waiting time at airfields 
and that fleet size has an opposing impact on airlift operation completion 
times and delivery flow times. The study has also demonstrated that the 
approximation method based model was much more efficient than the 
simulation model, utilizing only 2% of the time taken by the latter model 
to complete analysis, but at the expense of potential loss in accuracy. The 
authors further suggested that the combination of the two techniques 
would likely yield better performance than using either of them 
standalone, and warrants future work. 
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2. Related Work in DES 

DES is a modeling technique widely used to simulate systems where the 
phenomena of interest changes value or state at discrete points in time, rather than 
continuously across the time horizon [5]. As an alternative to the traditional time¬ 
stepping simulation, DES provides a much more efficient means of modeling such 
systems as it skips through all dormant moments in time where there are no occurrences 
that would matter to the simulation outcome. DES is particularly useful in supporting 
analysis work with its inherent abilities to compress/expand time, control sources of 
variation, restore system state, stop anytime for review and facilitate replications [2]. The 
following are examples of some recent studies done using DES to support the analysis 
work: 

• Ouerghi [6] has employed DES together with X3D visualization in his 
thesis work to look into problems related to ground traffic incursions and 
provide insights into possible cases that could result in potential accidents. 
Specifically, models mimicking aircraft arrivals and departures in an 
airport were developed to analyze the impact as the aircraft try to gain 
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access to the taxiway and runway at the same time. The findings 
concluded that the approach has demonstrated “a proof-of-concept 
capability worthy of future work.” 

• Wong and Ong [7] have demonstrated the feasibility of using DBS and the 
multi-agent system (MAS) to validate an air defense plan in their thesis 
work. In their study, MAS was used to generate an aggressor’s air strike 
plans based on tactics described in air strike doctrines with DBS models 
constructed to simulate the air defense assets and their interaction with the 
aggressor’s fighters. The developed system has also proven useful for air 
defense planners for looking into the dynamics of the causal effects 
between their air defense plans against the various possible strike plans. 

• Alexander [8] has explored DBS in the manufacturing process setting to 
analyze cycle time and timing interactions between process phases as an 
alternative to the conventional approach of using static methods to lay out 
the batch sequencing and scheduling with tools like Microsoft Project or 
Microsoft Bxcel. A sample DBS model was developed to assess the water- 
for-injection (WBI) system usage under some proposed batch sequence 
improvements, which will drive up its demand. The simulation result has 
surfaced the critical factor for achieving the most desirable WBI system 
performance, which was to increase the storage capacity. It has also 
successfully demonstrated the DBS capability of providing a reasonable 
performance approximation of the WBI system, as well as the 
manufacturing systems. 

E. ORGANIZATION 

This report is organized into the following chapters to provide a structured flow 
on how the thesis work was conceived through its deliverable end: 

• Chapter I - Introduction . This chapter introduces the problem statement 
and provides the objective and scope set for the thesis work. It also 
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provides background information on Project SEA-15 for readers to better 
understand the basis and considerations made for this thesis work, as well 
as the other related work in the same field. 

• Chapter II - Methodology . This chapter describes the general 
methodology adopted for this work, covering the development approach, 
operation analysis, performance measures and the software development 
environment. 

• Chapter III - Baseline Airlift Operation Model . This chapter describes the 
purpose, modeling approach, assumptions, design and implementation of 
the baseline airlift operation model, including the simulation findings. 

• Chapter IV - Final Airlift Operation Model . This chapter describes the 
modeling approach and differences (versus the baseline model), and the 
design and implementation of the final airlift operation model. 

• Chapter V - Testing and Verification . This chapter describes the testing 
and verification work conducted for the final airlift operation model. 

• Chapter VI - Design of Experiments . This chapter describes the various 
experiments conducted to demonstrate the final airlift operation model’s 
capability, compare the results under different simulation modes and 
evaluate the load transfer capability of the recommended Phase Zero force. 

• Chapter VII - Conclusion . This chapter summarizes the thesis findings 
and provides recommendations for future work on the developed model to 
better support the intended objectives. 
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II. METHODOLOGY 


A. DEVELOPMENT APPROACH 

An iterative development approach was adopted to allow for a baseline model to 
be developed quickly in the early project phase based on available information to 
demonstrate the feasibility of using DES to address the issues under study. The model 
could then be used as the platform, if still applicable, for the incremental build up of its 
details and capability to meet the end objective. The adopted approach was meant to 
facilitate the refinement and realignment of the software model, if required, as more 
information was gathered over the project phase. 

For the baseline model, the same high-level considerations and parameters used in 
Project SEA-15 were adopted so as to first verify whether an alternative DES model 
could produce or support the force structure solutions as recommended by that project. 
Once verified, the model output could also serve as a proxy for Project SEA-15, i.e., in 
areas where there is no documented information, for comparison with the final model 
output. For example, the project report only stated that the required missions could be 
completed within the given time, but it did not provide the expected completion time. In 
order to cut down on the development time, existing DES components developed under 
the OA3302 System Simulation course work will be utilized to formulate the baseline 
model. 

B. OPERATION ANALYSIS 

1. Airlift Operation in Project SEA-15 

The Civil Support mission defined in Project SEA-15 was comprised of two key 
missions; to support populace life-sustenance by saving lives and providing/ facilitating 
humanitarian relief assistance to the victims, and to restore critical infrastructure so as to 
stabilize the affected area and restore it to normalcy [1]. Airlift support is essential to 
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accomplish these missions, being the only means for transporting the required resources 
into the affected area as assumed by that project, i.e., taking worst case situations where 
ah other forms of access are cut off. 

Based on Project SEA-15’s final recommended force structure, the platforms that 
have direct involvement in the air operations were three ship classes, namely JMSDF 
DDH class destroyer, LPD-17 and JHSV, and the two helicopter types: CH-53K and SH- 
60S. These platforms will herein be referred as JMSDF, FPD-17, JHSV, CH-53 and SH- 
60 respectively. The project has identified the forces’ shipboard cargo capacity and its 
airlift capacity as the crucial attributes in accomplishing the missions. However, the 
importance of the shipboard cargo capacity was established from the overall sea-based 
storage perspective with no further analysis on how the load distribution across the ships 
would impact the actual airlift operation in executing the final delivery to site. 

2. Airlift Operation Process 

A literature research was conducted on the airlift operation process in order to 
identify the involved elements that have an influential effect on the operation. Several 
references have to be used to piece together the process that is of relevance to the study 
context with some assumptions made. The Shipboard-Helicopter Operational Procedures 
Manual [9] and Multiservice Helicopter Sling Foad: Basic Operations and Equipment 
manual [10] were the two main reference documents used. With that, the airlift operation 
workflow was broadly categorized into six phases (elements) as summarized below, 
supported by a central management system responsible for planning and coordinating the 
involving activities: 

• Preparation Phase . This is the phase prior to the aircraft arrival, where the 
load is moved to the landing spot from the holding space (if necessary) and 
set up for the loading to minimize the actual load-up time. The load can 
be airlifted two ways: inside the aircraft or below the aircraft suspended 
from the cargo hook (known as sling load operation) [10]. For this study, 
the load type and its airlift methods will be based on that defined for 
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Project SEA-15, i.e., cargo and equipment as sling load, while passengers 
are to be transferred inside the aircraft. For sling load, the ground crew 
must check to ensure that the load is properly prepared, rigged, and 
inspected for sling loading [10]. 

• Loading Phase . This is the phase where the aircraft arrives and the load is 
physically transferred to it. For sling load operation, the hook-up team 
will stay by the load for the hook-up and the approaching aircraft will be 
directed into position over the load by a signalman. When the aircraft gets 
in position and is in steady hover, the hook-up team will perform the hook¬ 
up and ensure that the connection (cargo hook and apex fitting) is secured, 
while grounding the cargo hook prior to any contact and throughout the 
process. The hook-up team will then get clear of the spot and the 
signalman will direct the aircraft to move up for a final visual check on the 
load before giving the take-off signal [10]. In the case of passenger 
loading, the aircraft will have to be grounded and chocked, at minimum, 
when the ship is stationary and in the case of ship underway, TALON or 
primary tie downs will have to be used before transferring passengers [9]. 

• Delivery Phase . This is the phase where the aircraft delivers the load from 
the ship to the designated target area. With sling load operations, there 
may be restrictions on the aircraft airspeed and maneuvering capabilities in 
order to maintain the load stability. 

• Unloading Phase . This is the phase where the aircraft arrives at the target 
site and unloads. The landing site would have been prepared with the 
ground crew standing by to receive the load prior to the aircraft’s arrival. 
Similar to the lading process, the aircraft will be directed into position by 
the signalman on the ground. For sling load operations [11], the aircraft 
will lower the load to the ground at the release point and then hover to one 
side before the signalman issues the “release load” sign to prevent the apex 
fitting from falling on the load. The aircrew are generally the ones 
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opening the cargo hook to release the load, and in the event that they fail 
to do so, the ground crew will step in to manually release the load. Once 
the load is properly released, the aircraft will be given the “take-off’ signal 
to return to ship. For the unloading of passengers, the aircraft will have to 
be grounded without the need for chock or tie downs. 

• Recovery Phase . This is the phase where the aircraft returns to the ship 
from the designated target area. At this juncture, the aircraft would have 
been informed of which ship to head to for the next assignment or to seek 
service support. 

• Servicing Phase . This is the phase where the aircraft is temporarily “taken 
ouf ’ of the mission to be serviced. There are two aspects to the servicing: 
refuel and repair. Helicopter refueling operations on ships can either be 
cold (engines off) or hot (rotors turning or engines operating). Cold 
refueling may be accomplished by pressure or gravity while hot refueling 
is limited to the use of pressure only [12]. Repair (or corrective 
maintenance) is necessary when the aircraft encounters failure and is 
deemed no longer “fif’ for the mission. Most helicopter maintenance is 
conducted on the flight deck of the ship. 

In a multi-ship environment, the airlift aircraft can be assigned to any ship to pick 
up the load so long as the loading spot can accommodate that aircraft type. As for 
servicing support, it depends on whether the ship has the facilities set up to support that 
aircraft type. 

The final airlift operation model was designed based on this abstraction of the 
process, which is described in a later chapter. 
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c. 


PERFORMANCE MEASURES 


1. Primary Measures 

The performance measures defined under Project SEA-15 for the Civil Support 
mission would naturally be included for the models developed under this thesis work, 
since they were the primary parameters of immediate importance used to define the force 
structure; they are described in the following subsections. 

(a) Measure of Effectiveness (MOE) / Measure of Performance 
(MOP) for Civil Support Mission 

As highlighted in Chapter I, there were three mission scenarios established 
for the Phase Zero force to support the Latin American populace following a natural 
disaster of different severity levels. Its role is only to provide “temporary critical support, 
while a more suitable and substantial force can be formed and dispatched, and not as 
complete civil relief’ [1]. The MOEs listed in the following table were defined and the 
associated MOPs are detailed in the next table. 


S/N 

Performance Measure 

Requirements 

B 

Personnel Supported 

1. 

Affected population to be assisted for 



• Low Severity Scenario 

50,000 pax 


• Mean Severity Scenario 

100,000 pax 


• High Severity Scenario 

150,000 pax 

2. 

Seriously injured medical assistance: 

5% of affected population 

B. 

Supply Delivered 

3. 

Eood 

2.5 lbs per person per day 

4. 

Water 

0.5 gal per person per day 

5. 

Shelter 

50% of population affected 


Table 2. MOE Eor Civil Support Mission (after [1]) 
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S/N 

Performance Measure 

B 

Personnel Supported 

1. 

“Camp” sites provide for 20,000 displaced personnel per site. 

2. 

One doctor and four nurses for every 400 injured. 

3. 

One surgeon and two assistants for every 800 injured, in addition to the doctors and 
nurses required. 

4. 

50% of doctors accessed off site via telecommunications. 

B. 

Supply Delivered 

5. 

Eirst supplies to be delivered within 24 hours. 

6. 

All supplies to be delivered within five days. 

C. 

Overall 

7. 

Eive-day endurance prior to subsequent force arrival. 

8. 

Penetration inland from sea (with ships stationed five nm offshore) for : 

• Eow Severity Scenario: five miles 

• Mean Severity Scenario 25 miles 

• High Severity Scenario: 50 miles 

9. 

Sea based command center with 200nm communications range. 

10. 

Adequate communications capability to support operations including remote doctor 
telecom. 


Table 3. MOP For Civil Support Mission (after [1]) 


(b) Consolidated Measures for Airlift Operation 

Based on the defined MOE/MOP, and having taken into consideration the 
other resources required to support the operation, the Project SEA-15 team has further 
consolidated and derived the following sets of performance measures in Table 4 to be 
used for the task force. The measures under Section C of the table are the ones specific 
for the airlift operation. Essentially, the performance measures for the airlift operation 
have been decomposed to the maximum delivery rates (per day) for the three different 
load types, namely cargo, equipment and passengers. 
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S/N 

Parameters 

Scenario Severity 

Unit 



Low 

Mean 

High 


A. 

Storage 



1. 

Store (in lbs) 

718,000 

1,429,500 

2,141,000 

lbs 

2. 

Store (in ft3) 

33,362 

66,458 

99,553 

ft3 

3. 

Vehicle 

2,220 

3,520 

5,780 

ft2 

B. 

Personnel 

170(158) 

292 

506 (491) 

pax 

4. 

Medical 

43 

83 

123 

pax 

5. 

Marines 

127 

209 

383 

pax 

C. 

Airlift 



6. 

Max Cargo 

413,600 

825,900 

1,238,200 

Ibs/day 

7. 

Max Equipment 

6 

11 

16 

sets/day 

8. 

Max Passenger 

32 

72 

99 

pax/day 


Table 4. Consolidated Measures For Civil Support Mission (after [1]) 


2. Detailed Measures 

Based on the airlift operation process described in earlier sections, the following 
are the additional parameters deemed essential for measuring operation effectiveness 
and/or providing insights to the operation workflow efficiency for conducting 
operational/tactical level analysis, and hence incorporated in the final model: 

• Mission Completion Time . This is time taken for all the loads to be 
delivered to the designated target site (or affected area). 

• Mission Sorties . This is the total number of delivery sorties flown in order 
to transport all the loads to the designated target site with breakdown for 
each aircraft type. 

• Aircraft Utilization . This is the overall utilization rate for all airlift aircraft 
in the task force over a mission day with breakdown for each aircraft type. 
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The “idle” state is defined as the period where the aircraft is ready for a 
delivery sortie but with no assignment given. 

• Landing Spot Utilization . This is the overall utilization rate for all landing 
spots onboard the ships over a mission day with breakdown for each ship. 
The “idle” state is defined as the period where the landing spot is not used 
for any ongoing activity or in standby (planned) for an impending activity. 

• Crew Utilization . This is the overall utilization rate for all logistics crew 
onboard the ship over a mission day with breakdown for each ship. The 
“idle” state is defined as the period where the crew is not supporting any 
ongoing activity. 

• Duration of Aircraft in Various Operation Phases . This is the average time 
the aircraft spent in a particular phase of the operation (e.g., delivery, 
recovery, etc.) over a mission day. 

• Load Delivered Over Time . This is the quantity of the various load types 
delivered to the designated target sites measured at fixed time intervals 
over a mission day. 

The baseline model was not meant to support this level of analysis by objective. 

D. SOFTWARE DEVELOPMENT ENVIRONMENT 

The following are the software tools and development environment used for 
constructing the models. 

1. Java 

Java is a free, open-source High Level Language (HLL) developed by Sun 

Microsystems and released in 1995 as a core component of Sun Microsystems' Java 

platform. The language’s syntax is very much derived from C and C-i-i- but has a simpler 

object model and fewer low-level facilities. Portability is the key strength of Java, which 

allows applications written in the language to run similarly on any supported 

hardware/operating-system platform. This is achieved by compiling the Java language 
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code to bytecode (class file) instead of directly to platform-specific machine code, which 
can be run on any Java Virtual Machine (JVM) regardless of computer architecture. End- 
users will use a Java Runtime Environment (JRE) installed on their own machine for 
standalone Java applications, or in a Web browser for Java applets [13]. 

2. Simkit 

Simkit is a free, open-source programming toolkit developed by Professor Arnold 
Buss of NPS to create DES models from an Event Graph methodology, i.e., the simplest 
and most natural way of presenting the model. It is written in Java and runs on any Java 
2 platform and modern Web browsers, and is installable from the Web [14]. 

Every element in an Event Graph model has a corresponding element in Simkit, 
which uses a component framework based on a listener design pattern. Basic models 
encapsulating a single Event Graph are implemented in Simkit by subclassing the 
SimEntityBase class, i.e., an abstract base class that implements most of the functionality 
required by a DES component. The component framework relies on two forms of the 
Eistener Pattern, the SimEventEistener and the PropertyChangeEistener patterns, to allow 
modelers to connect the basic models together to create larger models of greater 
complexity. This component framework is called Eistener Event Graph Objects (EEGO). 
Eigure 3 illustrates the conceptual design on how two basic components, i.e.. Arrival 
Process and Multi-Server Queue, are linked through a SimEventEistener to create a 
simple queuing model using Simkit [15]. 

Simkit also incorporates a framework for generating random variates and numbers 
to support simulation using different probability distributions without the need for any re- 
editing of the source code and recompilation. This capability is particularly important for 
the EEGO framework as it is undesirable to have every conceivable random variable 
implemented as a different component class [15]. 
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3. NetBeans Integrated Development Environment (IDE) 

NetBeans [17] is a free, open-source IDE for software developers that is easy to 
install and use straight out of the box and runs on multiple platforms including Windows, 
Linux, Mac OS X and Solaris. It comes with a suite of tools that allows developers to 

• create professional desktop applications using its GUI Builder with Swing 
Application Framework and Beans Binding support, 

• build Web applications using Ajax, JavaScript and CSS with support for 
frameworks including JSF, Struts, Spring, and Hibernate, 

• create, test and debug GUI applications that run on mobile phones, set-top 
boxes, and PDAs, with support for JavaFX Mobile and the Java ME SDK 
3.0 Platform, and 

• create open-source projects and host them on Kenai.com. 

NetBeans features language-aware editors for JavaFX, JavaScript, CSS, Python, 
PHP, Groovy and Grails, Ruby and Ruby on Rails, including code completion, 

22 















documentation pop-ups, and debugging integration. It also incorporates C/C++ editor, 
debugger, project templates, support for multiple project configurations, remote 
development, and packaging of completed projects. 
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III. BASELINE AIRLIET OPERATION MODEL 


A. DESIGN 

As highlighted in Chapter II, the baseline model was meant to be a simplified 
model that can be quickly assembled to capture the essence of the study question scenario 
in order to set one’s bearing. The model is essentially designed based on the queuing 
concept with parallel-servers and multiple customer types. In this case, the aircraft are 
modeled as the “servers” and the load as the “customers,” as described below: 

• The different loads are generated at the onset of the simulation and form 
their respective queues waiting to be to be airlifted (served) as and when 
the aircraft are available. 

• The number of loads that can be airlifted per sortie (service) is subject to 
the aircraft’s capacity. 

• The service duration is the round-trip travel time taken to cover the 
distance between the ship and the target area, based on the aircraft speed 
for each leg (an aircraft flies slower when it carries a sling load) plus the 
loading and unloading time. 

• The queue that can be served will depend upon the aircraft’s airlift 
capability. For example, SH-60 is incapable of airlifting equipment [1] 
and hence will not serve that particular queue. 

• The queue to serve first (i.e., load-to-aircraft assignments) will further 
depend on the aircraft’s relative transfer advantage, in terms of their 
capacity ratio, so as to optimize the airlift resources. For example, while 
the SH-60 has lower absolute capacities in transporting both passengers 
and cargo, as compared to CH-53, it is relatively more efficient for 
carrying passengers based on the capacity ratio of 12-55 (pax) versus 
4,500-27,000 (lbs) respectively. For this reason, the SH-60 will always 
serve the passengers first. 
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The simulation will run and stop in accordance with the duration defined, which 
in this case is modeled as the daily operating hours for airlift operation. 

B. ASSUMPTIONS 

Based on the above-mentioned design concept, the following are the further 
considerations and assumptions made, which are consistent with those made in Project 
SEA-15 [1] where applicable: 

• Only aircraft types in the recommended force structures were modeled, 
i.e., SH-60 and CH-53. 

• The airlift operation was modeled on a daily-operation basis and, in this 
case, to meet the maximum delivery rate as required for the task force, 
based on the defined scenarios. 

• The load hook-up, delivery, drop-off and recovery for each aircraft sortie 
are collapsed and treated as a single round-trip process with a deterministic 
time factor that is only dependent on the load type for each defined 
mission scenario. 

• The loads are consolidated and supplied from a single source (disregarding 
the fact that they could be stored on different ships). 

• All load types are ready and waiting to be airlifted at the landing spots. 

• There are unlimited landing spots, i.e., all aircraft can perform hook-ups 
concurrently. 

• The refueling time for each aircraft is treated as a single time block 
(regardless of the number of refueling operations), deducted from the daily 
operating hours. 

• The expected failure and repair time for each aircraft type are accounted 
for using operational availability to pro-rate the “usable hours” based on 
the reduced operating hours (i.e., after deducting the refueling time). 
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• A basic set of statistical utilities are incorporated to generate data similar 
to those from the Project SEA-15 so that comparisons can be made. 

C. IMPLEMENTATION 

The baseline airlift operation model is implemented in Simkit. It is comprised of 
two components, the LoadCreator and AirliftServer. The SimEventListener structure is 
depicted in Eigure 4. The parameters and state variables for the model are listed in the 
next two tables (which will be referenced in the follow-on event graphs) with the model 
component details provided in the subsequent subsections. 


Load 


Airlift 

Creator 

N 

Servers 



Eigure 4. SimEventEistener Structure for Baseline Airlift Operation Model 


S/N 

Field 

Parameters 

1. 

Hi 

Total number to be transferred for each load type i, i.e., i = 0, 1 and 2 for 
cargo, equipment and passengers respectively. 

data type: int 

2. 

ts(CH)J 

Sequence of possibly random service times (i.e., sortie times) for CH-53 
aircraft type to transfer load type i. 

data type: simkit.random.RandomVariate 

3. 

ts(SH)J 

Sequence of possibly random service times (i.e., sortie times) for SH-60 
aircraft type to transfer load type i. 

data type: simkit.random.RandomVariate 

4. 

CCHJ 

Transfer capacity of CH-53 aircraft type for load type i. 

data type: int 

5. 

CSHJ 

Transfer capacity of SH-60 aircraft type for load type i. 

data type: int 

6. 

kcH 

Total number of CH-53 aircraft type. 
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S/N 

Field 

Parameters 



data type: int 

7. 

ksH 

Total number of SH-60 aircraft type. 

data type: int 


Table 5. Parameters for Baseline Airlift Operation Model 


S/N 

Field 

State Variables 

1. 

Ni 

Number of arrivals for load type i, i.e., i = 0, 1 and 2 for cargo, equipment 
and passenger respectively; initial value is 0. 

data type: int 

2. 

Qi 

Remaining quantity of load type i; initial value is 0. 

data type: int 

3. 

Mi 

Quantity transferred for load type i; initial value is 0. 

data type: int 

4. 

ScH 

Number of available CH-53 aircraft type for load transfer; initial value is 
kviH- 

data type: int 

5. 

SsH 

Number of available SH-60 aircraft type for load transfer; initial value is 
ksH- 

data type: int 

6. 

Fch 

Number of CH-53 sorties flown (i.e., took off); initial value is 0. 

data type: int 

7. 

Fsh 

Number of SH-60 sorties flown (i.e., took off); initial value is 0. 

data type: int 

8. 

UcH 

Cumulative flight time for the CH-53 sorties flown; initially undefined. 

data type: double 

9. 

UsH 

Cumulative flight time for the SH-60 sorties flown; initially undefined. 

data type: double 

10. 

T 

Mission time based on the last completed sortie; initially undefined. 

data type: double 


Table 6. State Variables for Baseline Airlift Operation Model 
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1 . 


LoadCreator Component 


The component is responsible for creating all the loads for the three different load 
types at the simulation onset and passing the individual load items to the AirliftServers as 
and when they are created. The following figure depicts the component event graph and 


the specific events are described in Table 7. 


(i<no- I) 



{N2=N2+ 1} 


Figure 5. Event Graph for LoadCreator Component 
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S/N 

Event 

Description 

1. 

Run 

Performs initialization of all load type arrivals (Ni) to zero and 
immediately triggers the other three events at the start of 
simulation. 

2. 

ArrivalBatch_0 

Creates individual cargo item and passes it to AirliftServers. The 
total transfer quantity is created by looping through the event for 
that number of times. 

3. 

ArrivalBatch_l 

Same as ArrivalBatch_0 event but for equipment load type. 

4. 

ArrivalBatch_2 

Same as ArrivalBatch_0 event but for passenger load type. 


Table 7. Events for LoadCreator Component 


2. AirliftServers Component 

The component is responsible for modeling the whole airlift operation for both 
aircraft types. The sequential arrivals of the load (at time 0) will trigger the appropriate 
aircraft to start their respective airlift operations when the mounting numbers in the queue 
reaches the aircraft capacity or at the end of the load arrivals. The remaining number in 
queue (Qt+i) after each new sortie is computed using the max function, i.e., picking the 
maximum between 0 and the value of subtracting the load capacity (c) from the 
remaining number in queue (Qt), as depicted by the following mathematical notation: 


Qt + \ = max(0,(g,-c)) 


The load transfer amount (jt) will either be the load capacity, if the remaining 
existing number in queue is bigger than the load capacity, or otherwise, the existing 
number in queue, as depicted by the following mathematical notation: 


{c,Q,>c 
yQ,, otherwise 


The following figure depicts the component event graph and the specific events 


are described in Table 8. 
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Figure 6. Event Graph for AirliftServers Component 
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S/N 

Event 

Description 

1. 

Run 

Performs initialization for the following state variables: 

• initialize remaining quantity for each load type (QO to zero 

• initialize transferred quantity for each load type (Mi) to zero 

• initialize number of available CH-53 aircraft type (Sen) to its 
total number (ken) 

• initialize number of available SH-60 aircraft type (Ssh) to its 
total number (ksn) 

• initialize number of CH-53 sorties flown (Fch) to zero 

• initialize number of SH-60 sorties flown (Fsh) to zero 

• initialize mission time for last completed sortie (T) to zero 

2. 

ArrivalBatch_0 

Listens for cargo item arrival from LoadCreator and increments 
the remaining quantity (Qo) each time. 

Triggers the appropriate StartService event and provides the load 
type identifier if the conditions are met, which is dependent on 
the available aircraft capability and capacity, as well as what 
other load types are left to be transferred (as discussed under the 
design concept). 

3. 

AiTivalBatch_l 

Same as ArrivalBatchJ) event but for equipment load type. 

4. 

ArrivalBatch_2 

Same as ArrivalBatchJ) event but for passenger load type. 

5. 

StartServiceCH 

Commences an airlift sortie for CH-53 aircraft and performs state 
transition for the following variables: 

• decrease number of available CH-53 aircraft type (Sen) by 
one 

• increase number of CH-53 sorties flown (Fch) by one 

• decrease remaining quantity for the load type (Qi) using max 
function, i.e., Qt + \ = max(0, {Q, - c)) 

Computes load transfer amount (j) using the cited formula, i.e., 

. ]c,Q,>c 

[Q,, otherwise 

Triggers EndServiceCH event after ts(CH) i time delay, passing 
load transfer amount and load type identifier as argument. 

6. 

EndServiceCH 

Completes the airlift sortie for CH-53 aircraft and performs state 
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S/N 

Event 

Description 



transition for the following variables: 

• increase number of available CH-53 aircraft type (SCH) by 
one 

• increase transferred quantity for the load type (Mi) by the 
load transfer amount (j) 

• timestamp the mission time for last completed sortie (T) 

Triggers StartServiceCH event immediately and provides the 
load type identifier if the conditions are met, depending on the 
aircraft’s capability and its priority load, as well as the remaining 
load quantity. 

7. 

StartServiceSH 

Same as StartServiceSH event but for SH-60 aircraft type. 

8. 

EndServiceSH 

Same as EndServiceSH event but for SH-60 aircraft type. 


Table 8. Events for AirliftServers Component 


D. TESTING SETUP AND RESULTS 

1. Input Data 

As the main objective is to verify whether the alternative DES approach would 
support Project SEA-15 findings on the recommended force structure using future force 
assets, the testing has adopted the same input data as the project [1]. Table 9 depicts the 
aircraft parameters, and Table 10 summarizes the scenario requirements and settings, as 
well as the computed capability for the force structure. The capability is essentially 
measured by the excess capacity for transferring the cargo load type, conditional on 
meeting the transfer requirements for the other two load types, based on the data that was 
presented in Project SEA-15 report. 

The testing was performed for all three scenarios against the suggested 
capabilities for the force structure (Section B of Table 10) based on the 7.65 effective 
operating hours for the day. In other words, the suggested capacities for the various load 
types are injected into the model as the quantities to be transferred within the defined 
time. A comparison can then be made with the model outputs, based on the quantity 

delivered, resource utilization and any additional comments generated by the model. 
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S/N 

Parameters 

SH-60 

CH-53 

m 

Capacity and Capability 


11. 

For Cargo 

4,500 lbs 

27,000 lbs 

12. 

For Equipment 

Not Capable 

2 sets 

13. 

For Personnel 

12 pax 

55 pax 


Table 9. Aircraft Parameter Input Data for Baseline Airlift Operation Model 


S/N 

Scenario 

Scenario Severity 

Low 

Mean 

High 

B 

Load Transfer Requirement 

1. 

For Cargo (lbs) 

413,600 

825,900 

1,238,200 

2. 

For Equipment (sets) 

6 

11 

16 

3. 

Eor Personnel (pax) 

32 

72 

99 

B. 

Load Transfer Capability 

4. 

Eor Cargo (lbs) 

1,300,000 

(314%) 

855,000 

(103%) 

1,377,000 

(111%) 

5. 

Eor Equipment (sets) 

6 (100%) 

11 (100%) 

16 (100%) 

6. 

Eor Personnel (pax) 

32 (100%) 

72 (100%) 

99 (100%) 

C. 

Aircraft Quantity (i.e., the force structure recommended) 

7. 

Eor CH-53 (ea) 

1 

2 

7 

8. 

Eor SH-60 (ea) 

2 

2 

2 

D. 

Operating Profile 

9. 

Normal Operating Hours (hr) 

12 

10. 

Refuel Time and Non-Mission 
Overheads (hr) 

3 

11. 

Operational Availability (Ao) 

0.85 

12. 

Effective Operating Hours (hr) 
[i.e.,((9)-(10))*(ll)] 

7.65 
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S/N 

Scenario 

Scenario Severity 

Low 

Mean 

High 

D. 

Round-Trip Time for CH-53 

13. 

For Cargo (hr) 

0.11 

0.51 

0.91 

14. 

For Equipment (hr) 

0.11 

0.51 

0.91 

15. 

For Personnel (hr) 

0.23 

0.52 

0.81 

D. 

Round-Trip Time for SH-60 

16. 

For Cargo (hr) 

0.13 

0.61 

1.10 

17. 

For Equipment (hr) 

N.A. 

N.A. 

N.A. 

18. 

For Personnel (hr) 

0.24 

0.58 

0.92 


Table 10. Scenario Requirement Input Data for Baseline Airlift Operation Model (after [1]) 

The round-trip time for transferring personnel is relatively longer versus the other 
two load types for the low severity scenario, and shorter for the high severity scenario. 
This is because the round-trip time has a fixed loading/unloading time component and a 
varying traveling time component, which is distance-dependent. As the higher severity 
scenarios have a longer associated travel distance, the resultant round-trip time for 
transporting passengers becomes relatively shorter due to its longer loading/unloading 
time. 


2. Simulation Results 

The following figures are the output results generated by the model for the three 
test scenarios. Table 11 summarizes the test results with comparison to the suggested 
capability from Project SEA-15. 
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Simulation duration set: 7.65 hours 





CH-53 

SH-60 

Total 

Number of platforms deployed : 

1 

2 

3 

Cargo transferred (in lbs) : 

1007500 

292500 

1300000 (100%) 

Equipment transferred (in sets) : 

6 

N.A. 

6 (100%) 

Passengers transferred (in pax) : 

0 

32 

32 (100%) 

Sorties flown : 

41 

68 

109 

Average Utilization : 

60.43% 

59.76% 

60.09% 

Number of cargo left : 

Olbs 



Number of equipment left : 

0 sets 



Number of passengers left : 

0 pax 



All loads have been transferred. 




Time last sortie completed delivery : 

4.62 hours 




Figure 7. Results for Low Severity Scenario using Baseline Airlift Operation Model 

based on Project SEA-15 Findings 


Simulation duration set: 7.65 hours 





CH-53 

SH-60 

Total 

Number of platforms deployed : 

2 

2 

4 

Cargo transferred (in lbs) : 

648000 

81000 

729000 (85%) 

Equipment transferred (in sets) : 

11 

N.A. 

11 (100%) 

Passengers transferred (in pax) : 

0 

72 

72 (100%) 

Sorties flown : 

32 

26 

58 

Average Utilization : 

100.00% 

100.00% 

100.00% 

Number of cargo left : 

63000 lbs 



Number of equipment left : 

0 sets 



Number of passengers left : 

0 pax 



There are still loads in transition. 




Time last sortie completed delivery : 

7.65 hours 




Figure 8. Results for Mean Severity Scenario using Baseline Airlift Operation Model 

based on Project SEA-15 Findings 
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Simulation duration set: 7.65 hours 





CH-53 

SH-60 

Total 

Number of platforms deployed : 

7 

2 

9 

Cargo transferred (in lbs) : 

1296000 

22500 

1318500 (95%) 

Equipment transferred (in sets) : 

16 

N.A. 

16 (100%) 

Passengers transferred (in pax) : 

0 

99 

99 (100%) 

Sorties flown : 

58 

16 

74 

Average Utilization : 

96.31% 

100.00% 

98.15% 

Number of cargo left : 

Olbs 



Number of equipment left : 

0 sets 



Number of passengers left : 

0 pax 



There are still loads in transition. 




Time last sortie completed delivery : 

7.25 hours 




Figure 9. Results for High Severity Scenario using Baseline Airlift Operation Model 

based on Project SEA-15 Findings 


S/N 

Parameters 

SEA-15 

Baseline Model Results 

Capability 

Capability 

Resource Utilization 

1 


Low Severity Scenario 

1. 

Cargo (lbs) 

1,300,000 

1,300,000 

(100%) 

660.09% 

2. 

Equipment (sets) 

6 

6 (100%) 

3. 

Passenger (pax) 

32 

32 (100%) 

B. 

Mean Severity Scenario 

4. 

Cargo 

855,000 

729,000 (85%) 

1100.00% 

5. 

Equipment 

11 

11 (100%) 

6. 

Passenger 

72 

72 (100%) 

C. 

High Severity Scenario 

7. 

Cargo 

1,3770,000 

1,318,500 

(95%) 

98.15% 

8. 

Equipment 

16 

16 (100%) 
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S/N 

Parameters 

SEA-15 

Baseline Model Results 

Capability 

Capability 

Resource Utilization 

9. 

Passenger 

99 

99 (100%) 



Table 11. Test Results for Baseline Airlift Operation Model versus Projeet SEA-15 

Reported Data 


The test results have shown ineonsistencies with the findings from Project SEA-15: 

• Eor the low severity scenario, the model is able to deliver all the loads 
within the given timeline but the low resource utilization rate of about 
60% suggested that the task force is capable of delivering more load, i.e.. 
Project SEA-15 could have under-specified the transfer capability. 

• Eor the mean severity scenario, the resource utilization rate is 100% but 
the cargo quantity delivered is only 85%, suggesting that Project SEA-15 
could have over-specified the transfer capability in this case. 

• Similar to the high severity scenario, the cargo quantity delivered did not 
meet 100%, but in this case, the resource utilization is at 98.15%. Based 
on the additional information generated by the model output (refer Eigure 
8), i.e., the observed number of cargo left being zero and the comment that 
“there are still loads in transition,” it can now be inferred that all loads 
have already been picked up but delivery is incomplete because there are 
still delivery sorties transiting to the target site. This explains why the 
utilization rate is not 100%, as some aircraft would have completed their 
last delivery sorties and were in “idle” state when the simulation ended. 
Again, this suggested an over-specification by Project SEA-15 on the 
transfer capability. 

Given that these inconsistencies were found, a thorough verification was 
conducted on the model algorithms as well as the Project SEA-15 reported data. 
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3. Verification Findings 

The verification work has shown that the capability figures presented in the 
Project SEA-15 report were incorrect, based on mathematical computation and 
optimization analysis using linear programming. The optimization model was formulated 
using the Solver utility in Windows Excel software and the input parameters were based 
on the same ones used by Project SEA-15 and the baseline airlift model as summarized in 
the earlier tables (Table 9 and Table 10). 

Eor the high severity scenario case, the load transfer capabilities for the various 
load types, and the maximum number of CH-53 sorties that can be conducted (and 
completed) within the given timeline were used as the constraints for the optimization 
model to determine the minimum number of SH-60 sorties required. Eifty-six CH-53 
sorties (48 and eight for transporting cargo and equipment respectively) and 27 SH-60 
sorties (18 and nine for transporting cargo and passengers respectively) were the output 
figures computed by the model. By summing up the timings required for each of these 
sorties, it can be shown that 1,377,000 lbs of cargo cannot be delivered within 7.65 hrs 
while meeting the transfer capabilities for the other two load types. The following table 
illustrates the required sorties that would have been imposed on each aircraft in order to 
meet the stated capabilities, which clearly shows that the two SH-60s will not complete 
the sorties in time. 
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Aircraft 

Sortie type (number of sorties / time taken in hrs) 

Total duration 


for Equipment 

for Passengers 

for Cargo 

(hrs) 

CH-53#1 

2/1.82 

0/0 

6/5.46 

7.28 

CH-53#2 

1/0.91 

0/0 

7/6.37 

7.28 

CH-53#3 

1/0.91 

0/0 

7/6.37 

7.28 

CH-53#4 

1/0.91 

0/0 

7/6.37 

7.28 

CH-53#5 

1/0.91 

0/0 

7/6.37 

7.28 

CH-53#6 

1/0.91 

0/0 

7/6.37 

7.28 

CH-53#7 

1/0.91 

0/0 

7/6.37 

7.28 

SH-60#1 

0/0 

5/4.6 

9/9.9 

14.5 

SH-60#2 

0/0 

4/3.68 

9/9.9 

13.58 


Table 12. Example of the Aircraft Sorties Required to meet the Load Transfer Capability 
stated in Project SEA-15 Report for High Severity Scenario 


Using the same methodology, the capability figures stated in the Project SEA-15 
report for the low and mean severity scenarios were also proven to be incorrect, as 
suggested by the baseline airlift model. 

The same methodology was also applied to the baseline airlift model to verify its 
output results. Eor the mean and high severity scenarios, the figures for the cargo 
quantity delivered in Eigure 8 and Eigure 9, i.e., 729,000 and 1,318,500 lbs respectively, 
were used as input to the model so as to generate the required sorties to be verified by the 
optimization model. Eor the low severity scenario case, a direct mathematical calculation 
suggested that the cargo transfer capability should be 2,232,000 lbs, which was injected 
to the model to generate the required output for verification. The next three figures are 
the results from the airlift model, and Table 13 summarizes the sorties required, with a 
comparison to that generated by the optimization model. 
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Simulation duration set: 7.65 hours 





CH-53 

SH-60 

Total 

Number of platforms deployed : 

1 

2 

3 

Cargo transferred (in lbs) : 

1728000 

504000 

2232000 (100%) 

Equipment transferred (in sets) : 

6 

N.A. 

6 (100%) 

Passengers transferred (in pax) : 

0 

32 

32 (100%) 

Sorties flown : 

67 

115 

182 

Average Utilization : 

98.75% 

99.64% 

99.19% 

Number of cargo left : 

Olbs 



Number of equipment left : 

0 sets 



Number of passengers left : 

0 pax 



All loads have been transferred. 




Time last sortie completed delivery : 

7.64 hours 




Figure 10. Force Structure Capability for Low Severity Scenario using Baseline Airlift 

Operation Model 


Simulation duration set: 7.65 hours 





CH-53 

SH-60 

Total 

Number of platforms deployed : 

2 

2 

4 

Cargo transferred (in lbs) : 

648000 

81000 

729000 (100%) 

Equipment transferred (in sets) : 

11 

N.A. 

11(100%) 

Passengers transferred (in pax) : 

0 

72 

72(100%) 

Sorties flown : 

30 

24 

54 

Average Utilization : 

99.96% 

94.59% 

97.27% 

Number of cargo left : 

Olbs 



Number of equipment left : 

0 sets 



Number of passengers left : 

0 pax 



All loads have been transferred. 




Time last sortie completed delivery : 

7.65 hours 




Figure 11. Force Structure Capability for Mean Severity Scenario using Baseline Airlift 

Operation Model 
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Simulation duration set: 7.65 hours 





CH-53 

SH-60 

Total 

Number of platforms deployed : 

7 

2 

9 

Cargo transferred (in lbs) : 

1296000 

22500 

1318500 (100%) 

Equipment transferred (in sets) : 

16 

N.A. 

16 (100%) 

Passengers transferred (in pax) : 

0 

99 

99 (100%) 

Sorties flown : 

56 

14 

70 

Average Utilization : 

94.83% 

89.61% 

92.22% 

Number of cargo left : 

Olbs 



Number of equipment left : 

0 sets 



Number of passengers left : 

0 pax 



All loads have been transferred. 




Time last sortie completed delivery : 

7.25 hours 




Figure 12. Force Structure Capability for High Severity Scenario using Baseline Airlift 

Operation Model 



Table 13. Test Results Comparison for Baseline Airlift Operation Model 
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Based on the figures presented in Table 13, it can be shown that the sorties 
computed by the optimization model do sum up to the number generated by the baseline 
airlift model and hence, verify the validity of its simulation outcome. 

In the course of verification, data refinement was found to be necessary in order 
to overcome rounding errors caused by various sources (e.g., documented data, software 
tools, etc.) that could result in a very different outcome. For example, based on the 7.65 
effective operating hours for the day and the round-trip time for CH-53 to transfer cargo 
and equipment under the mean severity scenario (i.e., 0.51 hr.), a direct calculation will 
show that the aircraft can complete 15 sorties per day. However, using the 0.51 hr. as an 
input to the airlift model in the NetBean IDE, the model would suggest that the aircraft 
can only perform 14 sorties for the day. By decreasing the round-trip time value in the 
order of 10'^, the model will generate the “correct” answer of 15 sorties. 

4. Summary 

Table 14 summarizes the force structure capabilities suggested by the baseline 
airlift model as well as that stated in the Project SEA-15 report, both using the same input 
parameters. The presented figures for the airlift model are strictly based on the input 
parameters described in this chapter, which are related to the aircraft used for the airlift 
operation and not for the ships involved. Eor example, the model suggested that the 
cargo transfer capability is 2,286,000 lbs for the low severity scenario but the ships may 
not necessarily have the storage space or logistics crew to handle that load. 
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S/N 

Scenario 

Scenario Severity 

Low 

Mean 

High 

n 

Load Transfer Capability based on Project SEA-15 Report [1] 

19. 

For Cargo (lbs) 

1,300,000 

(314%) 

855,000 

(103%) 

1,377,000 

(111%) 

20. 

For Equipment (sets) 

6 (100%) 

11 (100%) 

16 (100%) 

21. 

For Personnel (pax) 

32 (100%) 

72 (100%) 

99 (100%) 

B. 

Load Transfer Capability based on Baseline Airlift Model 

22. 

For Cargo (lbs) 

2,286,000 

(522%) 

729,000 

(85%) 

1,318,500 

(106%) 

23. 

For Equipment (sets) 

6 (100%) 

11 (100%) 

16 (100%) 

24. 

Eor Personnel (pax) 

32 (100%) 

72 (100%) 

99 (100%) 

B. 

Aircraft Quantity (i.e., the force structure) 

25. 

Eor CH-53 (ea) 

1 

2 

7 

26. 

Eor SH-60 (ea) 

2 

2 

2 


Table 14. Test Results Comparison for Baseline Airlift Operation Model 


Based on the verified airlift model results, the foree structure does not meet the 
airlift requirement for the mean severity scenario. In order to satisfy the 825,900 lbs and 
the other two load type transfer requirements, the airlift model suggested that another 
CH-53 aircraft would be required, increasing the force structure to a three CH-53 and two 
SH-60 configuration, which would create excess capacity with an enhanced cargo 
transfer capability of 1,13M lbs (137%). Figure 13 depicts the simulation results for the 
suggested force structure using the load transfer capabilities as input for the load transfer 
requirements. 
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Simulation duration set: 7.65 hours 





CH-53 

SH-60 

Total 

Number of platforms deployed : 

3 

2 

5 

Cargo transferred (in lbs) : 

1053000 

81000 

1134000 (100%) 

Equipment transferred (in sets) : 

11 

N.A. 

11 (100%) 

Passengers transferred (in pax) : 

0 

72 

72 (100%) 

Sorties flown : 

45 

24 

69 

Average Utilization : 

99.96% 

94.59% 

97.27% 

Number of cargo left : 

Olbs 



Number of equipment left : 

0 sets 



Number of passengers left : 

0 pax 



All loads have been transferred. 




Time last sortie completed delivery : 

7.65 hours 




Figure 13. Revised Force Structure Capability for Mean Severity Scenario Using 

Baseline Airlift Operation Model 
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IV. FINAL AIRLIFT OPERATION MODEL 


A. DESIGN 

1. Modeling Approach 

The baseline model encapsulated the whole airlift operation as a single process 
with only three essential events, i.e., load arrival, start and end delivery. This level of 
abstraction limits the analysis to only those basic performance measures as shown in 
Chapter III. In order to support operational/ tactical level analysis to answer questions 
such as the operation impact due to unavailability of landing spots, aircraft failure, etc., 
the airlift operation needs to be modeled in greater depth. 

The final model mimics the airlift operation by abstracting the process into six 
main phases with a central management system responsible for planning and coordinating 
the involving activities as described in Chapter II. Figure 14 illustrates the broad-level 
modeling approach for the airlift operation workflow. 


JMSDF \ LPD-17 \ JHiv 



Preparation Loading/ Delivery/ Unloading 

Servicing Recovery 


Figure 14. Airlift Operation Workflow Modeling 
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The modeled task force was based on the final force structure recommended by 
Project SEA-15 comprising three ships, namely JMSDF, LPD-17 and JHSV, and nine 
aircraft, i.e., seven CH-53s and two SH-60s. The RQ-8 and Visby were excluded 
because they do not play a direct role in the airlift operation. Each ship is a unique entity 
having its own set of landing spots and logistics (or ground) crew to support the airlift 
operation with an allocated quantity of loads to be transferred. In this case, there are 
three load types to be transferred; cargo, equipment and passengers, as defined in Project 
SEA-15. Each set of logistics crew is assumed to be an independent group that is capable 
of performing all the subtasks involved in preparing the load and for the load-up. 

In terms of the workflow, all loads will first go through the preparation phase to 
be transferred from the holding area to the landing spot and set up for loading by the 
logistics crew. When the load is ready, the assigned aircraft (if available) will be called 
in for the load-up, again supported by the logistics crew. Once loaded up, the aircraft 
will commence the delivery sortie and the logistics crew and landing spots will be freed 
up to prepare for another loading. The aircraft will unload upon reaching the designated 
target site and recover back to the ship after that. If the aircraft is still in serviceable 
state, i.e., not requiring refueling or repair work, it will continue with the next airlift 
assignment. Otherwise, it will seek service support first, before continuing with the next 
assignment, in which case, a landing spot would be required for each aircraft servicing 
operation. For each of these six phases, there is an associated variable “service time” to 
perform the tasks involved, based on a mean value with a distribution function. The 
cycle will repeat itself for the whole mission duration until all the loads have been 
transferred. 

In essence, the logistics crew, landing spots and aircraft are direct resources 
supporting the airlift operation with the ships serving as depots to supply the load and 
provide facilities (other than landing spots) for the service support, e.g., fueling system, 
maintenance crew, etc., which are not explicitly modeled. The aircraft, however, can 
become a constraint to the operation at times, such as when they require service support, 
which then draws landing spots away from supporting the airlift operation. 
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Table 15 summarizes the parameters modeled for the baseline and final airlift 
operation models. 


S/N 

Parameters 

Baseline Model 

Final Model 

1. 

Aircraft airlift 
capacity 

Specific to 

oad types 

2. 

Aircraft airlift 
capability 

Specific to load types 

3. 

Load-to-aircraft 

assignment 

Based on relative advantage using capacity ratio 

4. 

Preparation time 

All loads assumes ready for 
airlift at mission start time 

Independent stochastic time 
factor 

5. 

Loading time 

Treated as single round-trip 
process with deterministic time 
factor 

Independent stochastic time 
factor 

6. 

Unloading time 

Independent stochastic time 
factor 

7. 

Aircraft delivery 
time 

Independent stochastic time 
factor 

8. 

Aircraft recovery 
time 

Independent stochastic time 
factor 

9. 

Aircraft refueling 
time 

Block reduction on the daily 
operating hours (deterministic) 

Independent stochastic time 
factor 

10. 

Aircraft time-to- 
failure 

Based on Aq on the reduced 
operating hours (deterministic) 

Independent stochastic time 
factor 

11. 

Aircraft time-to- 
repair 

Independent stochastic time 
factor 

12. 

Aircraft 

Individua 

entities 

13. 

Ships 

Treated as single entity 

Individual entities 

14. 

Landing spots on 
ship 

Unlimited 

Finite and ship-specific 

15. 

Logistics crew on 
ship 

Unlimited 

Finite and ship-specific 


Table 15. Parameters Modeled for the Baseline and Final Airlift Models 
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2. Broad Level Design 

There is a radical change in the design between the baseline and the final model, 
i.e., switching from a “load arrival” to a “landing spot arrival” triggered process. This 
switch is primarily to enable the “central management system” to plan ahead for the load 
type and the quantity that a landing spot needs to prepare, based on the next anticipated 
aircraft that will be available for the load-up. 

The design for the operation process is best described using a flow chart, which is 
depicted in Figure 15 and summarized as follows: 

• The simulation commences with the creation of resources (aircraft, ships, 
logistics crew and landing spots) and allocation of loads to the various 
ships based on user inputs. This is followed by a check to identify any 
failed aircraft (i.e., aircraft that has encountered failure), which will be 
transferred to the “Need Support List.” 

• A landing spot from each ship will be triggered next and removed from the 
available list to check for a new task, and to find out whether there are 
aircraft requiring service support (refuel and/or repair) and if so, whether 
there are enough landing spots already set aside to support them (in the 
“Support LS list,” which is empty at this point). The consideration for the 
number of landing spots is further discussed under the Support Landing 
Spot Allocation subsection. If, indeed, a landing spot is required, it will 
then check whether there is already an aircraft waiting for the service 
support and if so, to commence the service or otherwise, it will be added to 
the “Support LS list” to standby for the aircraft. 

• If the landing spot is not required for service support, it will next check for 
an available logistics crew, remaining load left for transfer, and unassigned 
aircraft, which there will be for all of them at this juncture. In the event 
that any of these is not available, which will happen as the mission 
proceeds, the landing spot will be reinserted back to the available list and 
wait for the next trigger event to occur. 
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Figure 15. Flow Chart for Final Airlift Operation Model 
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• Based on some preset criteria, which is further discussed under the Load 
Allocation subsection, an assignment will be issued, specifying the 
assigned aircraft, load type and the quantity that the landing spot needs to 
prepare for. The landing spot will then proceed with load preparation and 
use a set of logistics crew to support it. 

• Upon completion of the load preparation, the landing spot will check 
whether the assigned aircraft is ready. If the aircraft is ready, loading will 
commence, and once completed, the aircraft will begin its delivery sortie 
and the landing spot will restart the “check task” process. As for the 
relieved crew, it will first check whether there is a landing spot with its 
assigned aircraft ready and waiting for loading (the priority pair) and if 
there is, loading will commence for that pair. Otherwise, the “check task” 
event will be triggered if there are other available landing spots and the 
crew will just stand by for the next assignment. 

• If the aircraft is unavailable, the logistic crew will be relieved to support 
another assignment and will perform the checks described earlier. As for 
the landing spot, it will stand by and wait for the assigned aircraft to be 
ready unless the aircraft has encountered failure. Under such 
circumstances, the landing spot will either “return” the load to the holding 
space and restart the “check task” process, or request another unassigned 
aircraft to “take over” the prepared load. The decision will depend on the 
reassignment scheme used for that simulation run, which is further 
discussed under the Landing Spot Reassignment subsection. 

• As the aircraft commences the delivery sortie, it will also put in a request 
for the next assignment (by adding the aircraft to the Holding A/C list). 
The aircraft will provide the expected return time to allow for the 
assignment detailing, taking into consideration the (mean) refueling time if 
it requires a refuel upon return to ship. 
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• The aircraft will next reach the target site and unload, following which it 
will return to ship. Should the aircraft fail anytime between the loading 
and recovery phase, it will continue and complete the assignment on the 
assumption that the failure is not catastrophic, which would warrant an 
alternative action to be taken immediately. An aircraft failure would be 
made known instantly to trigger any available landing spot to start the 
“check task” process. If the aircraft has put in a request for a next 
assignment and had not been given one yet, the request will be withdrawn. 
Otherwise, the assigned landing spot will request either a new task or a 
replacement aircraft, as described earlier. 

• Upon returning to ship, the aircraft will check whether it needs service 
support. If it does, and there are landing spots reserved to support that, the 
service will commence. Otherwise, the aircraft will have to wait and be 
added to the Waiting A/C List. 

• If service support is not required and the aircraft has a next assignment 
with the assigned landing spot and logistics crew available, loading will 
commence and the follow-on process is as described earlier. If the aircraft 
has not been assigned, or any of the required resources are not available, 
the aircraft will be added to appropriate list and wait for the next trigger. 
Should the aircraft have failed while waiting, it will be transferred to the 
“Need Support List” to seek support. 

(a) Support Landing Spot Allocation 

The number of landing spots that can be set aside for service support was 
designed to be user-input controllable using two parameters, except under a special 
condition. The first parameter is the minimum number of landing spots each ship must 
have at any one time to cater to activities directly related to the airlift operation, i.e., the 
preparation and loading events. In other words, the difference between this number and 
the total number of landing spots is the maximum allowable support landing spots a ship 
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can set aside to provide service support. The second parameter is the maximum 
allowable support landing spots that the whole fleet (of three ships) can set aside to 
provide service support, which forms the ceiling regardless of whether the individual 
ships have reached their respective quota. 

This “maximum rule” will apply for each ship under all conditions except 
when it has completed all the load transfers, which in this case makes sense to open up 
the landing spots to provide service support, since they will not be utilized otherwise. 

(b) Load Allocation 

The model has incorporated two user-selectable schemes to manage the 
load allocation for the airlift assignment. As highlighted under the baseline model design 
in Chapter III, the load-to-aircraft assignment is driven by the aircraft’s relative transfer 
advantage based on its capacity ratio in order to optimize the aircraft usage, and the same 
logic is inherited in this final model. 

The first scheme adopts a micro management approach whereby the 
allocation of load is optimized at the ship-level only. In other words, the model will only 
check for the remaining load onboard the ship and determine the optimal load type that 
the landing spot should prepare for the next anticipated aircraft that will be available. For 
example, if the next available aircraft is a SH-60, which has the relative advantage of 
transporting passengers, passengers would be assigned to the landing spot if it is among 
the load types remaining onboard the associated ship. Otherwise, the landing spot will be 
assigned the next optimal load that is onboard the ship for the SH-60; the model will not 
consider holding off the aircraft for another ship that still has passengers onboard. 

The second scheme, on the other hand, will do that in an attempt to 
optimize the load allocation at the fleet-level. The general concept is to get the next 
available aircraft for both aircraft types and, based on their expected available time 
difference and the remaining load in the fleet to determine the load type and aircraft for 
the assignment. The model does so by performing the following: 
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• With a landing spot request for a new assignment, the model will check for 
the next available aircraft in the holding list for both the aircraft types (i.e., 
CH-53 and SH-60). If there is only one aircraft type on the list, or the 
optimal load type is available onboard the ship for the aircraft type with an 
earlier expected available time, the model will assign the load type and 
aircraft to the landing as per the first scheme. 

• Otherwise, the model will compute the expected available time difference 
for the aircraft and compare it to a user-defined threshold value. This 
threshold value is essentially the wait time that the user is willing to accept 
in order to have the “more suited” aircraft pick up the remaining load 
onboard that ship. If the time difference exceeds this threshold value, the 
model will proceed to assign the load for first available aircraft as per the 
first scheme. For example, if the threshold value is five minutes and a 
CH-53 is expected to be available seven minutes before the next SH-60, 
the model will assign passengers to the CH-53 if it is the only load type 
left onboard the ship, even though the optimal load type (equipment) for 
the CH-53 may be available onboard the other ships, and the SH-60 is in 
the holding list waiting for its assignment. 

• However, if the time difference is within the threshold value, and the 
optimal load type for the earlier available aircraft can be found onboard 
the other ships, the model will assign the later available aircraft and its 
optimal load type to the landing spot instead. For the cited example, the 
model would have assigned the SH-60 and passengers as the load type to 
the landing spot, and hold off the CH-53 for a later assignment. 

• In the event where the optimal load type for an aircraft type has been fully 
transferred, the same logic applies for the next optimal load type, and so 
forth. 
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As the study is about a new naval force structure, the two options will at 
least allow one to analyze the impact of employing different management schemes to the 
said situation. 


(c) Landing Spot Reassignment 

The model has two user-selectable schemes incorporated to handle 
situations when a landing spot has prepared the load but the assigned aircraft failed 
before it could pick up the load. For the first scheme (i.e., mode #0 as depicted in the 
flow chart diagram), which is a substitution approach, the landing spot will find the next 
available replacement of the same aircraft type as the failed aircraft so that the prepared 
load can be readily transferrable to the newly assigned aircraft. The second scheme (i.e., 
mode #1 in the flow chart diagram) is essentially a “start fresh” approach whereby the 
prepared load will be returned to the holding space to free up the landing spot to check 
for the next task. 

Again, the options are implemented to analyze the various possibilities of 
handling the stated situations. 

B. ASSUMPTIONS 

Based on the above-mentioned design concept, the following are the further 
considerations and assumptions made: 

• All ships have facilities to support the refueling and repair for both aircraft 
types. 

• All ships are stationary and positioned at the same distance from the 
designated target sites. 

• No adverse weather conditions that will substantially impact the aircraft 
airspeed. 

• There are ample landing spots and ground crew support at the target sites, 
i.e., no queuing required for unloading. 
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• The recovery of the cargo nets, pallets, and hoisting slings used for the 
sling operations can be performed as part of the recovery sortie after 
transporting passengers to the target site with no additional lead-time. 

C. IMPLEMENTATION 

The final airlift operation model was implemented using simkit, which is 
comprised of five unique components, namely Aircraftinitializer, AircraftServer, 
ShipServer, Scheduler and Recorder. The SimEventListener structure for the mode is 
depicted in Figure 16. 



Figure 16. SimEventListener Structure for Final Airlift Operation Model 
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The parameters and state variables for the model are listed in the next two tables 
with the SimEntity objects and the model components described in the follow-on 
subsections: 


S/N 

Field 

Parameters 

1. 

ai 

Ship entity with identifier i, i.e., i = 0, 1 and 2 for JMSDF, LPD-17 and 
JHSV respectively. 

data type: int 

2. 

bi 

Landing spot entity for ship entity with identifier i. 

data type: LandingSpot 

3. 

Ck 

Aircraft entity of type k, i.e., k = 0 and 1 for CH-53 and SH-60 
respectively. 

data type: int 

4. 

m 

Total number of ships. 

data type: int 

5. 

Hi 

Total number of landing spots for ship entity with identifier i. 

data type: int for ShipServer and int[] for Scheduler 

6. 

llLi 

Minimum number of landing spots that must be available at any one time 
for direct airlift operation support (i.e., for load preparation and loading 
activities only) for ship entity with identifier i. 

data type: int 

7. 

ns 

Maximum number of landing spots for the whole fleet that can be set aside 
for support services (refuel and repair). This is herein referred to as 
maximum number support landing spots 

data type: int 

8. 

Ti 

Total number of logistics crew for ship entity with identifier i. 

data type: int 

9. 

QiLI] 

Quantity allocated to ship entity with identifier i for load type 1, i.e., 1 = 0, 
1, 2 for cargo (in lbs), equipment (in sets) and passengers (in pax) 
respectively. 

data type: int[] 

10. 

qT[i] 

Total load quantity to be transferred for load type 1, i.e., 1 = 0, 1, 2 for 
cargo (in lbs), equipment (in sets) and passengers (in pax) respectively. 
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S/N 

Field 

Parameters 



data type: int[] 

11. 

Pk 

Total number of aircraft of type k. 

data type: int 

12. 

Ski 

Transfer capacity for aircraft of type k for load type 1. 

data type: int 

13. 

ti 

Time interval for recording the load quantity delivered over the mission 
time (simulation duration). 

data type: double 

14. 

tpikU] 

Sequence of possibly random service times to perform load preparation of 
load type j by ship with identifier i for aircraft type k. 

data type: simkit.random.RandomVariate[] 

15. 

tLikU] 

Sequence of possibly random service times to perform loading for load 
type j by ship with identifier i for aircraft type k. 

data type: simkit.random.RandomVariate[] 

16. 

tDk[j] 

Sequence of possibly random sortie times to deliver load type j from ship 
to target site for aircraft type k. 

data type: simkit.random.RandomVariate[] 

17. 

tRk[j] 

Sequence of possibly random sortie times to recover from target site to 
ship after unloading load type j for aircraft type k. 

data type: simkit.random.RandomVariate[] 

18. 

tuk[j] 

Sequence of possibly random service times to unload load type j at target 
site for aircraft type k. 

data type: simkit.random.RandomVariate[] 

19. 

tRFk 

Sequence of possibly random service times to refuel aircraft type k. 

data type: simkit.random.RandomVariate 

20. 

tRPk 

Sequence of possibly random service times to repair aircraft type k. 

data type: simkit.random.RandomVariate 

21. 

tpk 

Sequence of possibly random time-to-failure for aircraft type k. 

data type: simkit.random.RandomVariate 

22. 

tw 

Expected arrival time difference that a ship is wiling to wait in order to get 
a better aircraft match (optimized) for the remaining load onboard the ship, 
based on the unassigned aircraft in the holding list. This parameter is only 
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S/N 

Field 

Parameters 



applicable under Allocation Mode #1 scheme. 

data type: double 


Table 16. Parameters for Final Airlift Operation Model 


S/N 

Field 

State Variables 

1. 

Ah 

List of assignments that have been issued for the airlift operation with the 
details on the involved landing spot, aircraft, amount and type of load 
transferred, timing for various phases, etc. 

data type: java.util.LinkedList<Item> 

2. 

Ah 

List of sorted aircraft of all types based on their expected time available for 
next assignment; initial value is 0. The list is used by the Scheduler for 
detailing assignments and is herein referred to as the aircraft holding list. 

data type: : java.util.LinkedList<Aircraft> 

3. 

Afik 

List of ready aircraft of type k with new assignment but its assigned 
landing spot is unavailable yet; initial value is 0. The list is herein referred 
to as the ready aircraft list. 

data type: java.util.LinkedList<Aircraft> 

4. 

Apk 

List of aircraft of type k with new assignment but it is not ready yet; initial 
value is 0. The list is herein referred to as the planned aircraft list. 

data type: java.util.LinkedList<Aircraft> 

5. 

As 

List of aircraft requiring support service (refuel and/or repair) that has not 
been allocated a support landing spot yet; initial value is 0. 

data type: java.util.LinkedList<Aircraft> 

6. 

Aw 

List of aircraft requiring support service that has returned to ship and is 
waiting for an available support landing spot, which may or may not have 
been allocated one; initial value is 0. 

data type: java.util.LinkedList<Aircraft> 

7. 

Ci 

Number of available logistics crew for ship entity with identifier i; initial 
value is total number of logistics crew for that ship (ri). 

data type: int 

8. 

D[i] 

Quantity delivered to site for load type 1; initial value is 0. 

data type: int[] 
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S/N 

Field 

State Variables 

9. 

Dk[i] 

Quantity delivered to site by aircraft type k for load type 1; initial value is 
0. 

data type: int[] 

10. 

D[i][t] 

Quantity delivered to site for load type 1 at time interval t; initial value is 0. 

data type: int[][] 

11. 

Fk 

Number of airlift sorties flown by aircraft type k; initial value is 0. 

data type: int 

12. 

Lai 

List of available landing spots for ship entity with identifier I; initial value 
is total number of landing spots for that ship (ni). 

data type: java.util.LinkedList<LandingSpot> 

13. 

H 

List of records on the timing when an aircraft has made a request for 
new/next assignment and when it is given one or it has retracted the 
request to due to aircraft failure. 

data type: java.util.LinkedList<Entry> 

14. 

Ic 

Indicator for the delivery completion for all load type, i.e., 0 and 1 for 
incomplete and complete respectively; initial value is 0. 

data type: int 

15. 

Lai 

List of available landing spots for ship with identifier i; initial value is null. 

data type: java.util.LinkedList<LandingSpot> 

16. 

Lu 

List of landing spots with active ongoing activities (preparing or loading) 
directly related to an assignment for s with identifier i; initial value is null. 
The list is herein referred to as active landing spot list. 

data type: java.util.LinkedList<LandingSpot> 

17. 

Lpi 

List of loaded landing spots with ready aircraft waiting for the next set of 
available logistics crew to perform loading for ship entity with identifier i; 
initial value is null. The list is herein referred to as the priority list. 

data type: java.util.LinkedList<LandingSpot> 

18. 

Lr 

List of landing spots requiring a replacement aircraft to take over the load 
prepared for an earlier assigned aircraft that has failed for ship with 
identifier I; initial value is null. This variable is only applicable under the 
Replacement Mode #0 scheme. 

data type: java.util.LinkedList< LandingSpot > 

19. 

Ls 

List of landing spots reserved to perform support services for the whole 
fleet; initial value is null. The list is herein referred to as support landing 
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S/N 

Field 

State Variables 



spot list. 

data type: java.util.LinkedList<LandingSpot> 

20. 

Lwi 

List of loaded landing spots for ship with identifier i waiting for aircraft 
arrival to perform next load-up for ship entity with identifier I; initial value 
is null. The list is herein referred to as standby landing spot list. 

data type: java.util.LinkedList<LandingSpot> 

21. 

NAk 

Number of available aircraft of type k; initial value is 0. 

22. 

NAk 

Number of aircraft of type k in process of loading up; initial value is 0. 

23. 

Nok 

Number of aircraft of type k in process of delivering load from ship to 
target site; initial value is 0. 

24. 

Nuk 

Number of aircraft of type k in process of unloading at target site; initial 
value is 0. 

25. 

NRk 

Number of aircraft of type k in process of recovering from target site to 
ship; initial value is 0. 

26. 

NfiFk 

Number of aircraft of type k in process of refueling; initial value is 0. 

27. 

Nfipk 

Number of aircraft of type k undergoing repair; initial value is 0. 

28. 

Nwk 

Number of aircraft of type k waiting for load-up or support service; initial 
value is 0. 

29. 

Nai 

Number of available landing spots for ship with identifier i; initial value is 
0. 

data type: int 

30. 

Nl! 

Number of landing spots with active ongoing activities (preparing or 
loading) directly related to an assignment for ship with identifier i; initial 
value is 0. 

data type: int 

31. 

Nsi 

Number of landing spots reserved to perform support services for ship 
entity with identifier i; initial value is 0. 

data type: int 

32. 

Nwi 

Number of standby landing spots awaiting for aircraft arrival to perform 
next load-up for ship entity with identifier i; initial value is 0. 

data type: int 

33. 

Qi[l] 

Remaining quantity of load type 1 for ship entity with identifier i; initial 
value is the total quantity of that load type allocated to the ship (qi[i]). 
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S/N 

Field 

State Variables 



data type: int[] for ShipServer and int[][] for Scheduler 

34. 

Q[i] 

Remaining quantity of load type 1 for the whole fleet; initial value is the 
sum of total quantity of that load type allocated to each ship. 

data type: int[] 

35. 

Qt[I] 

Total quantity of load type 1; initial value is 0. 

data type: int[] 

36. 

Tc 

The completion time when all load types have been transferred to target 
site; initial value is 0. 

data type: double 


Table 17. State Variables for Final Airlift Operation Model 


1. SimEntity Objects 

There are two categories of SimEntity objects created to support the simulation. 
The first category is used to model the real-world physical entities, i.e., aircraft, ship and 
landing spot. The second category is generated for keeping track of simulation data to 
support the simulation as well as for post-simulation review. 

(a) Aircraft SimEntity 

The Aircraft SimEntity is a generic object that models both the CH-53 and 
SH-60 aircraft types; the parameters defined for the object differentiate them. An 
Aircraft object is instantiated for each aircraft entity simulated in the scenario. The 
attributes defined for this object class are described in the following table. 
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S/N 

Attribute 

Description 

m 

Parameter 


1 . 

id 

Identifier for the aircraft entity. 

data type: int 

2. 

type 

Platform type for the aircraft entity, i.e., CH53 or SH60. 

data type: String 

3. 

capacity 

Transfer capacity for different load types for the aircraft 
entity. There are currently three different load types that the 
model is designed for, i.e., cargo, equipment and 
passengers, and an array (of three elements) is used to store 
the values in that sequence. 

data type: int[] 

4. 

speed 

Speed transiting between ship and target site for the aircraft 
entity. As the aircraft may travel slower when carrying 
load, especially during sling load operations, different 
speeds will need to be defined for the delivery and recovery 
phase. 

There are currently three different load types that the model 
is designed for, i.e., cargo, equipment and passengers, and a 
3x2 dimensional array is used to store the values with the 
row designated for the load type in the same sequence. The 
first column is meant for the delivery speed and the second 
for recovery speed. 

data type: int[][] 

5. 

meanHookOffr ime 

The meantime to hook-off (unload) the load from the 
aircraft entity. There are currently three different load types 
that the model is designed for, i.e., cargo, equipment and 
passengers, and an array (of three elements) is used to store 
the values in that sequence. 

data type: double[] 

6. 

minBufferTime 

Minimum buffer time that an aircraft must be able to hold in 
the air upon returning to ship in case there is no available 
landing spot for landing. The parameter is used for 
refueling considerations. 

data type: double 
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S/N 

Attribute 

Description 

7. 

minB ufferF actor 

Minimum buffer factor based on the travel distance between 
the ship and target site that an aircraft must cater for a sortie 
for refueling considerations. (For example, a factor of 0.1 
for a ship and the target area that are 50 nm apart means that 
the aircraft will only carry out the sortie if it has enough fuel 
to cover at least 110 nm.) 

data type: double 

8. 

maxDistance 

The maximum distance that the aircraft entity can travel in 
between refuels. 

data type: double 

B. 

State Variable 

9. 

needRepair 

A state for the aircraft entity to indicate that it needs repair. 
This value is referenced by the Scheduler to allocate a 
landing spot to support the service task. 

data type: boolean 

10. 

needRefuel 

A state for the aircraft entity to indicate that it needs to 
refuel. This value is referenced by the Scheduler to allocate 
a landing spot to support the service task. 

data type: boolean 

11. 

distanceTravelled 

The distance travelled by the aircraft entity since the start of 
simulation or last refuel, whichever is the later event. This 
value is referenced by the AircraftServer instances to 
determine when refueling is required. 

data type: int 

12. 

expectedRetumTime 

The expected time that the aircraft entity will return to ship, 
complete the refuel (if required) and be ready to execute the 
next assignment. This value is referenced by the Scheduler 
for detailing assignments. 

data type: double 

13. 

assignment 

Assignment that the aircraft entity has been given and is 
currently being executed, i.e., from the point loading 
commences till the aircraft returns to ship and is ready for 
its next assignment (including refueling and repairing 
work). 

data type: Item 
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S/N 

Attribute 

Description 

14. 

entry 

Record of when the aircraft entity has last requested an 
assignment and time when it was given one or when it 
retracted the request due to aircraft failure. 

data type: Entry 

15. 

nextEandingSpot 

Eanding spot that the aircraft is assigned to for the new/next 
assignment. 

data type: LandingSpot 

16. 

totalSorties 

Total number of sorties flown (or delivery made) by the 
aircraft entity. 

data type: int 

17. 

state 

Enumerator to indicate the current phase that the aircraft 
entity is in, that is, available with no assignment (0) waiting 
to execute next assignment (1), loading up (2), delivering 
load to target site (3), unloading (4), recovering to ship (5), 
refueling (6), and repairing (7). 

data type: int 

18. 

status 

Enumerator to indicate whether an aircraft entity has been 
given a new/next assignment, that is, not assigned (0) and 
assigned (1). 

data type: int 


Table 18. Attributes for Aircraft SimEntity Object 


(b) Ship SimEntity 

The Ship SimEntity is a generic object that can model any of the ship 
types, JMSDE, EPD-17 and JHSV; the parameters defined for the object differentiate 
them. A Ship object is instantiated for each ship entity simulated in the scenario. The 
attributes defined for this object class is described in the following table. 
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S/N 

Attribute 

Description 

B 

Parameter 

1. 

id 

Identifier for the ship entity. 

data type: int 

2. 

type 

Platform type for the ship entity, i.e., JMSDE, LPD17 or 
JHSV. 

data type: String 

3. 

totalLandingSpots 

Total number of landing spots for the ship entity. 

data type: int 

4. 

totalLogCrew 

Total number of logistics crew (set) on the ship entity. 

data type: int 

5. 

landingSpotList 

List of landing spot entities for the ship entity. 

data type: java.util.LinkedList<LandingSpot> 

B. 

State Variable 

6. 

allocatedLoad 

Quantity for each load type onboard the ship entity. 

data type: int[] 


Table 19. Attributes for Ship SimEntity Object 


(c) LandingSpot SimEntity 

The LandingSpot SimEntity is a generic object created to model the 
landing spots for all the ships. A LandingSpot object is instantiated for each landing spot 
as it needs to maintain its own unique states at any given time during simulation. The 
attributes defined for this object class is described in the following table. 
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S/N 

Attribute 

Description 

B 

Parameter 

1. 

id 

Identifier for the landing spot entity. 

data type: int 

2. 

associatedShipId 

Identifier for the ship entity that the landing spot is associated 
with, i.e., with value = 0, 1 and 2 for JMSDE, EPD-17 and 
JHSV respectively. 

data type: int 

B. 

State Variable 

3. 

assignment 

Airlift assignment (object) given to the landing spot. 

data type: Item 

4. 

supportAircraft 

Aircraft (object) that the landing spot is tasked to provide 
support services (refuel and repair) to. 

data type: Aircraft 


Table 20. Attributes for LandingSpot SimEntity Object 


(d) Item SimEntity 

The Item SimEntity object is created to keep track of each individual 
assignment data that is used to support the simulation, as well as for post-simulation 
review. Table 18 describes the attributes defined for the entity. 


S/N 

Attribute 

Description 

A. 

Parameter 

1. 

id 

Identifier for the assignment entity. 

data type: int 

B. 

State Variable 

2. 

assignmentTime 

The time when the assignment entity is created. 

data type: double 

3. 

landingSpot 

The landing spot entity that is assigned to this assignment 
entity. 

data type: LandingSpot 
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S/N 

Attribute 

Description 

4. 

aircraft 

The aircraft entity that is assigned to this assignment entity. 

data type: Aircraft 

5. 

loadType 

The load type to be transferred under this assignment. 

data type: int 

6. 

loadQuantity 

The quantity of the assigned load type to be transferred under 
this assignment. 

data type: int 

7. 

startPrepareTime 

The time when the load preparation starts. 

data type: double 

8. 

endPrepareTime 

The time when the load preparation ends. 

data type: double 

9. 

startLoadingT ime 

The time when the loading starts. 

data type: double 

10. 

endLoadingTime 

The time when the loading ends. 

data type: double 

11. 

startSortieTime 

The time when the assigned aircraft starts the sortie (leaves the 
ship). 

data type: double 

12. 

reachTargetTime 

The time when the assigned aircraft reaches the target site and 
start unloading. 

data type: double 

13. 

leaveTargetTime 

The time when the assigned aircraft completes unloading and 
leaves the target site. 

data type: double 

14. 

endSortieTime 

The time when the assigned aircraft returns to ship. 

data type: double 

15. 

startRefuelTime 

The time when the assigned aircraft starts refueling. 

data type: double 

16. 

endRefuelTime 

The time when the assigned aircraft ends refueling. 

data type: double 
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17. 

startRepairT ime 

The time when the repair work for the assigned aircraft starts. 

data type: double 

18. 

endRepairTime 

The time when the repair work for the assigned aircraft starts. 

data type: double 

19. 

readyTime 

The time when the assigned aircraft is ready to execute its next 
assignment, which marks the end of this assignment. 

data type: double 

20. 

expectedDuration 

The expected sortie duration, i.e., the time between when the 
assigned aircraft starts and ends a sortie. This duration is 
computed based on the sum of the travel time to and from the 
target site (dividing distance by speed), the mean time to 
unload and mean time to refuel (if the aircraft needs to be 
refueled upon return to ship for this assignment). 

data type: double 

21. 

actualDuration 

The actual sortie duration, i.e., the measured time between 
when the assigned aircraft starts and ends a sortie. 

data type: double 

22. 

remainingEoad 

The remaining quantity for all load types left to be transferred, 
after discounting the quantity to be transferred under this 
assignment. There are currently three different load types that 
the model is designed for, cargo, equipment and passengers. 
An array (of three elements) is used to store the values in that 
sequence. 

data type: int[] 


Table 21. Attributes for Item SimEntity Object 


(e) Entry SimEntity 

The Entry SimEntity object is used to keep track of when an aircraft is 
added and removed from the holding list to support the simulation as well as for post¬ 
simulation review. The following table describes the attributes defined for the entity. 


70 














S/N 

Attribute 

Description 

B 

Parameter 


1. 

id 

Identifier for the record entry entity. 

data type: int 

B. 

State Variable 


2. 

aircraft 

The aircraft entity that the record entry is created for. 

data type: Aircraft 

3. 

startTime 

The time when the record entry is created, i.e., when an aircraft 
requests for new/next assignment. 



data type: double 

4. 

endTime 

The time when the record entry is closed, i.e., when the aircraft 
gets its assignment or when it retracts the request because it 
encountered failure. 



data type: double 


Table 22. Attributes for Entry SimEntity Object 


2. Aircraftinitializer Component 

This component is responsible for the creation and initialization of the list of 
entities for each aircraft type. Two Aircraftinitializer components are therefore 
instantiated for the simulation, one for the CH-53 and the other for the SH-60 aircraft 
type. The following figure depicts the component event graph, and the specific events 
are described in Table 23. 
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Figure 17. Event Graph for Aircraftinitializer Component 


S/N 

Event 

Purpose 

1. 

Run 

Triggers the InitAircraft event immediately at the start of 
simulation. 

2. 

InitAircraft 

Creates aircraft entity, sets its parameters and initializes its 
state variables, i.e., 

• set aircraft identifier, 

• set aircraft type, 

• set aircraft capacity, 

• set aircraft speed, 

• set aircraft mean time for unloading the various load 
types, 

• set aircraft maximum range (i.e., before requiring 
refueling), 

• set aircraft minimum buffer time, 

• set aircraft minimum buffer factor, 

• initialize aircraft need for refuel to false, 

• initialize aircraft need for repair to false, 

• initialize aircraft expected return time to ship to zero. 
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• initialize aircraft’s next assigned landing spot to null, 

• initialize aircraft’s assignment to null, 

• initialize aircraft’s total sorties flown to zero, 

• initialize aircraft status to zero, 

• initialize aircraft state to zero, and 

• initialize aircraft travelled distance from zero for the first 
aircraft up to half the maximum range for the last aircraft 
with constant increment. This is to simulate some 
staggering in the refueling need for the aircraft fleet, 
which is more representative of actual operations. 

Loops itself for (pk - 1) times so as to generate the total 
number for that aircraft type, and passes the aircraft entity to 
Scheduler and AircraftServer instances via UpdateAircraftList 
and CreateAircraft event respectively. 

3. 

UpdateAircraftList 

Does nothing; meant to be heard by Scheduler. 

4. 

Create Air craft 

Does nothing; meant to be heard by AircraftServer instances. 


Table 23. Events for Aircraftinitializer Component 


3. AircraftServer Component 

The AircraftServer component is responsible for managing the entities of a 
specific aircraft type by keeping track of their status, and updates the Scheduler and 
ShipServer components as and when information is required to coordinate the activities. 
It is also responsible for generating the “aircraft-led” events, which fall under the 
delivery, unloading, recovery and servicing phases of the airlift operation process. The 
following two figures depict the component event graph, and the specific events are 
detailed in Table 24. 
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Figure 18. Event Graph for AircraftServer Component (Part 1) 
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Figure 19. Event Graph for AircraftServer Component (Part 2) 
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S/N 

Event 

Purpose 

1. 

Run 

Performs state initialization for the following variables at the 
start of simulation, i.e., 

• initialize the lists of ready aircraft (Ank) and planned 
aircraft (Apk) to null, 

• initialize the numbers of aircraft for the various recording, 
i.e., available, loading, delivery, unloading, recovery, 
refueling, repairing and waiting (Nau, Nlr, Ndu, Nuk, Nnk, 
Nrer, NRPk and Nwk respectively), to zero, 

• initialize the standby landing spot list (Lwi) to null, 

• initialize the number of load delivered (Qk[i]) by aircraft 
type k to zero, and 

• initialize the number of sorties flown (Fk) by aircraft type k 
to zero. 

2. 

Create Air craft 

Listens to Aircraftinitializer for newly created aircraft and 
performs the following: 

• update aircraft status and state accordingly, 

• increase the number of available aircraft (NAk) by one, and 

• trigger NeedSupport event after tpk time delay with the 
aircraft and support type (i.e., with value 1) passed on as 
argument to simulate a downstream aircraft failure. 

3. 

NeedSupport 

Does nothing; meant to be heard by Scheduler 

4. 

Tasking 

Listens to Scheduler for load assignment (via the assigned 
landing spot) and performs one of the following: 

• trigger MakeReady event and pass the assigned aircraft as 
argument if the aircraft is available, or otherwise 

• trigger MakePlan event for the assigned aircraft and pass 
the assigned aircraft as argument. 

5. 

MakeReady 

Adds aircraft to the ready list (ARk) and increases the number 
of waiting aircraft (Nwk) by one. 

6. 

MakePlan 

Adds aircraft to the planned list (Apk). 

7. 

CheckAircraft 

Listens to ShipServer instances for landing spot and checks 
whether its assigned aircraft is ready for next assignment. If 
the aircraft is ready, removes it from the ready list (ARk) and 
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assigns the landing spot to it. 

Triggers AircraftStatus event immediately with the aircraft 
readiness status passed on as argument. 

8. 

AircmftStatus 

Does nothing; meant to be heard by ShipServer instances. 

9. 

StartLoading 

Listens to ShipServer instances for landing spot to commence 
loading of its assigned aircraft and performs the following: 

• update the aircraft state accordingly, 

• decrease number of waiting aircraft (Nwk) by one, 

• remove landing spot from standby list (Lwi) if it is in it, 

• remove aircraft from the ready list (ARk), and 

• increase the number of loading aircraft (Nlr) by one. 

10. 

StandbyLoading 

Adds landing spot entity to the standby list (Lwi), i.e., to wait 
for the assigned aircraft to be ready for load-up. 

11. 

StartSortie 

Listens to ShipServer instances for an assigned aircraft to 
commence the delivery sortie and performs the following: 

• update the aircraft state accordingly, 

• timestamp mission time and update its assignment record, 

• increase number of sorties flown (Fr) by one, 

• decrease number of loading aircraft (Nlu) by one and add it 
to the number of delivery aircraft (Nok), 

• compute expected return time for aircraft, 

• trigger ReachTarget event after tokij] time delay to simulate 
travel time with the landing spot entity passed on as 
argument, 

• trigger NeedSupport event immediately with the aircraft 
passed on as argument together with the support type (i.e., 
value = 0), if it requires refueling upon return to ship, and 

• trigger UpdateAircraftList event immediately with the 
aircraft passed on as argument for Scheduler to detail the 
next assignment, if it does not require repair at this 
juncture. 

12. 

UpdateAircraft 

List 

Does nothing; meant to be heard by Scheduler. 

13. 

ReachTarget 

Reaches designated target area to start unloading and performs 
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the following: 

• update aircraft state and its travelled distance accordingly, 

• timestamp mission time and update its assignment record, 

• increase number of loads delivered (Qk[i]) by the load 
transfer amount as stored in its assignment record, 

• decrease number of delivery aircraft (Nok) by one add it to 
the number of unloading aircraft (Nuk), and 

• trigger LeaveTarget event next with tukij] time delay to 
simulate the unloading process and the aircraft is passed on 
as argument. 

14. 

LeaveTarget 

Completes unloading process with the aircraft returning to ship 
and performs the following: 

• update the aircraft state accordingly, 

• timestamp mission time and update its assignment record, 

• decrease number of unloading aircraft (Nuk) by one, add it 
to the number of recovery aircraft (NRk), and 

• trigger EndSortie event next with tRk[j] time delay to 
simulate the travel time and the aircraft is passed on as 
argument. 

15. 

EndSortie 

Completes the sortie and performs the following: 

• update aircraft state and its travelled distance accordingly, 

• timestamp mission time, compute actual time taken for 
sortie, update its assignment record, and 

• decrease the number of recovery aircraft (Nnk) by one. 

Triggers one of the following immediately with the aircraft 
passed on as argument based on the stated conditions: 

• SeekSupport event if the aircraft needs refueling and/or 
repair and increase the number of waiting aircraft (Nwk) by 
one, or otherwise 

• Ready event to indicate it is ready for next assignment. 

16. 

SeekSupport 

Does nothing; meant to be heard by Scheduler. 

17. 

StartRefuel 

Listens to Scheduler for aircraft to start refueling and performs 
the following: 
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• update aircraft state accordingly, 

• timestamp mission time and update its assignment record, 

• decrease number of waiting aircraft (Nwk) by one, 

• decrease number of refueling aircraft (Nkfr) by one, and 

• trigger EndRefuel event next with Irfr time delay to 
simulate the refueling process and the aircraft is passed on 
as argument. 

18. 

EndRefuel 

Completes refueling and performs the following: 

• update aircraft state, reset its refuel need and distance 
travelled accordingly, 

• timestamp mission time and update its assignment record, 
and 

• increase the number of refueling aircraft (Nkfu) by one. 

Triggers one of the following events immediately based on the 
stated conditions: 

• StartRepair event with the aircraft passed on as argument if 
aircraft needs to be repaired and increase number of 
waiting aircraft (Nwk) by one, or otherwise 

• Ready event with the aircraft passed on as argument and 
ReleaseLandingSpot event with the landing spot passed on 
as argument to relieve the landing spot for next tasking. 
The support aircraft for the landing spot is set to null. 

19. 

StartRepair 

Listens to Scheduler (and EndRefuel event) for aircraft to start 
the repairing work and performs the following: 

• timestamp mission time and update its assignment record, 

• decrease number of waiting aircraft (Nwk) by one, 

• increase number of repairing aircraft (Nkpr) by one, and 

• trigger EndRepair event next with Irpr time delay to 
simulate the repair process and the aircraft is passed on as 
argument. 

20. 

EndRepair 

Completes refueling and performs the following: 

• update aircraft state and reset its repair need and support 
aircraft accordingly, 

• timestamp mission time and update its assignment record 
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• decrease number of refueling aircraft (Nkfic) by one and 
add it to the number of available aircraft (NAk), 

• trigger ReleaseLandingSpot event immediately with the 
landing spot passed on as argument, 

• trigger Recheck event immediately, 

• trigger UpdateAircraftList immediately event with the 
landing spot passed on as argument to seek the next 
assignment, and 

• trigger NeedSupport event with Ifr time delay to simulate 
another downstream failure and the landing spot is passed 
on as argument together with the support code. 

21. 

Ready 

Prepares aircraft for next assignment and performs the 
following: 

• timestamp mission time and update aircraft’s assignment 
record before resetting its assignment record to null, 

• update aircraft state accordingly, and 

• increase number of available aircraft (Nar) by one. 

Triggers one of the following events immediately: 

• Handover event with assigned landing spot passed on as 
argument and remove aircraft from the planned list (Apk), if 
the aircraft is scheduled for next assignment and the 
assigned landing spot is ready to start loading, or 

• MakeReady event with the aircraft passed on as argument 
and Recheck event and remove aircraft from the planned 
list (Apk), is scheduled for next assignment but the assigned 
landing spot is not ready (still preparing the load), or 
otherwise 

• Recheck event. 

22. 

Handover 

Shortlists the landing spot for loading when the crew is next 
available since its assigned aircraft is ready by performing the 
following: 

• remove landing spot from standby list (Lwi), 

• increase number of waiting aircraft (Nwk) by one, 

• decrease the number of available aircraft (Nar) by one, and 

• add the aircraft to the ready list (ARk). 
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The event is meant to be heard by ShipServer instances as well. 

23. 

UpdateFailed 

Aircraft 

Removes aircraft from the ready list (Aru) if it is in ready state 
or otherwise from the planned list (Apk). 

24. 

Recheck 

Does nothing; meant to be heard by ShipServer instances. 

25. 

ReleaseLanding 

Spot 

Does nothing; meant to be heard by ShipServer instances. 

26. 

Update 

Replacement 

Aircraft 

Eistens to Scheduler for replacement aircraft and performs one 
of the following: 

• trigger MakeReady and Handover events with the aircraft 
and assigned landing spot passed on as argument 
respectively, if the aircraft is available, or otherwise 

• trigger MakePlan event with the assigned aircraft passed on 
as argument. 

27. 

UpdateLanding 

Spot 

Eistens to Scheduler for failed aircraft and removes its assigned 
landing spot from the standby list (LwO, i.e., if the landing spot 
is loaded and waiting for the aircraft to perform the load-up. 


Table 24. Events for AircraftServer Component 


4. ShipServer Component 

Initially, the ShipServer component is responsible for the creation and 
initialization of a specific ship entity. In this case, there are three ShipServer objects 
instantiated for the JMSDF, LPD-I9 and HJSV respectively. Each ShipServer object 
manages the resources onboard the ship, including the logistics crew and landing spots,by 
keeping track of their status, and updates the Scheduler and ShipServer components as 
and when information is required to coordinate the activities. It is also responsible for 
generating the “landing spot-led” events, which fall under the preparation and loading 
phases of the airlift operation process. The following two figures depict the component 
event graph and the specific events are detailed in Table 25. 
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Figure 20. Event Graph for ShipServer Component (Part 1) 
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Figure 21. Event Graph for ShipServer Component (Part 2) 
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1. 

Run 

Creates a ship entity (Uj) and sets/initializes its attributes at the 
start of simulation to: 



• 

set ship identifier i, i.e,. i = 0, 1 and 2 for JMSDF, LPD-17 
and JHSV respectively, 



• 

set number of landing spots, 



• 

set number of logistics crew. 



• 

set meantime for preparing the various load types, which is 
specific to the aircraft type used for the airlift. 



• 

set meantime for loading the various load types, which is 
specific to the aircraft type used for the airlift, and 



• 

create a list of landing spots and initializes it to null. 



Performs initialization of the following state variables for each 
ship with identifier i: 



• 

initialize number of available crew (Ci) to total number of 
logistics crew (ri). 



• 

initialize number of available landing spots (NAi) to total 
number of landing spots (ni), number of landing spots 
defined for other recording purposes, i.e., active, standby 
and support (NAi, NWi and NSi) to zero. 



• 

initialize the landing spot lists defined for the various 
recording, i.e., available, active, priority, standby and 
support ( LAi, LLi, LPi, LWi and LS respectively), to null, 
and 



• 

initialize remaining load (Qi[l]) to the quantity allocated to 
the ship (qil) for load type 1, i.e., 1 = 0, 1, 2 for cargo, 
equipment and passengers respectively. 



Triggers the InitLS and CreateShip events immediately 
afterward. 

2. 

InitLS 

Creates landing spot entity and sets/initializes its attributes to: 



• 

• 

• 

• 

• 

set landing spot identifier, 

set landing spot’s associated ship, 

initialize assignment to null, 

initialize support aircraft to null, and 

insert landing spot entity to the ship’s landing spot list. 
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Adds landing spot entity to the available landing spot list (Lai). 

Triggers the InitLS event immediately if the number of created 
landing spot entities is less than the ship’s total number of 
landing spots (ri) and increase the number created (counter) 
each time. 

3. 

InitOperation 

Removes first available landing spot from the list (LaO and 
decreases number of available landing spots (Nai) by one. 

Triggers CheckTask event immediately and passes landing spot 
as argument to Scheduler to check for new task, which could 
be an airlift assignment or provide support service. 

4. 

CreateShip 

Does nothing; meant to be heard by Scheduler and Recorder. 

5. 

CheckTask 

Does nothing; meant to be heard by Scheduler. 

6. 

Tasking 

Listens for tasking from Scheduler and triggers one of the 
following events immediately based on the tasking issued with 
the requesting landing spot entity passed on as argument, i.e., 

• StandbySupport, if landing spot is required to provide 
service support, or otherwise 

• StartPrepare, if there are loads to be transferred and crew is 
available, or otherwise 

• Reset. 

7. 

Standby Support 

Adds the landing spot to the support list (Ls), reserved to 
provide support services, and increases number of standby 
landing spots for the associated ship (Nsi) by one. 

8. 

Reset 

Inserts landing spot entity back to the available list (LaO and 
increases number of available landing spots (NaO by one. 

9. 

StartPrepare 

Commences load preparation for an airlift assignment and 
performs state transition for the following variables: 

• decrease number of available crew (Ci) by one, 

• add landing spot to the active list (Lo) and increase number 
of active landing spots (Nu) by one, 

• decrease remaining quantity (Qi[i]) by the load transfer 
amount (as stored in the landing spot’s assignment record), 
and 

• timestamp the mission time and update the assignment 
record. 

Triggers EndPrepare event after tpik time delay and passes the 
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landing spot as argument. 

10. 

EndPrepare 

Completes load preparation and performs state transition for 
the following variables: 



• 

increase number of available crew (CO by one, 



• 

remove landing spot from the active list (Lo) and decrease 
number of active landing spots (Nu) by one, and 



• 

timestamp the mission time and update the assignment 
record. 



Triggers one of the following events immediately with the 
landing spot passed on as argument: 



• 

EindReplacement event, if its assigned aircraft has been re¬ 
assigned (i.e., after it has failed and is being repaired), or 
otherwise 



• 

CheckAircraft event to check whether the aircraft is ready. 

11. 

CheckAircraft 

Does nothing; meant to be heard by AircraftServer instances. 

12. 

AircraftStatus 

Listens for aircraft status from AircraftServer instances and 
triggers one of the following events immediately with the 
landing spot passed on as argument: 



• 

EindReplacement event, if assigned aircraft is 
unserviceable, or otherwise 



• 

StartLoading event, if aircraft is available and in 
serviceable state with available crew, or otherwise 



• 

StandbyLoading and Recheck events for new task. 

13. 

StartLoading 

Commences loading for an airlift assignment and performs 
state transition for the following variables: 



• 

decrease number of available crew (CO by one. 



• 

add landing spot to active list (LlO and increase number of 
active landing spots (No) by one. 



• 

remove landing spot from standby list (Lwi) if it is in the 
list, and 



• 

timestamp the mission time and update the assignment 
record. 



Triggers EndLoading event after tLik time delay with the 
landing spot entity passed on as argument. 



The event is meant to be heard by AircraftServer instances as 
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well. 

14. 

StandbyLoading 

Adds landing spot entity to the standby list (Lwi) and increases 
the number of standby landing spots (NwO by one, to wait for 
the assigned aircraft to be ready for load-up. 

The event is meant to be heard by AircraftServer instances as 
well. 

15. 

Recheck 

Checks for available resources and performs one of the 
following: 

• triggers StartLoading event if there are available crew (Ci) 
and awaiting landing spot in the priority list (LPi). 
Removes the first landing spot from LPi and passes it as the 
argument, or 

• triggers CheckTask event if there are available logistics 
crew (Ci) and landing spot (LAi). Removes the first 
landing spot from LAi, decrease number of available 
landing spots (NAi) by one and pass landing spot as the 
argument together with current crew size, or 

• does nothing otherwise. 

16. 

FindReplacement 

Does nothing; meant to be heard by Scheduler. 

17. 

EndLoading 

Completes the loading for an airlift assignment and performs 
state transition for the following variables: 

• increase number of available crew (Ci) by one, 

• remove landing spot from active list (LLi) and decrease 
number of active landing spots (NLi) by one, 

• add landing spot to the available list (LAi) and increase 
number of available landing spots (NAi) by one, 

• timestamp the mission time and update the assignment 
record, and 

• hand over the assignment record to the aircraft and set the 
landing spot’s assignment to null. 

Triggers StartSortie and Recheck event immediately with 
aircraft entity passed on as argument for StartSortie. 

18. 

StartSortie 

Does nothing; meant to be heard by AircraftServer instances. 

19. 

Handover 

Listens to AircraftServer instances for ready aircraft that has an 
assigned landing spot waiting to start the next assignment. 

Triggers StartLoading event if there is crew (Ci) available or 
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otherwise, GetReady event. 

20. 

GetReady 

Adds landing spot to the priority list (Lpi) so that it will be 
activated for loading when the next crew is available. 

21. 

NeedSupport 

Listens to AircraftServer instances for aircraft requiring 
servicing (refuel and/or repair) and performs the following if 
there is available landing spot (Lai): 

• remove the first landing spot from Lai, 

• decrease number of available landing spots (Nai) by one, 
and 

• trigger CheckTask event and pass landing spot as the 
argument together with the crew size. 

22. 

ReleaseLanding 

Spot 

Listens to AircraftServer instances for completed support 
service work and performs the following: 

• remove landing spot from support list (Ls) and decrease 
number of support landing spots for the associated ship 
(Nsi) by one, and 

• add landing spot to available list (Lai) and increase number 
of available landing spots (Nai) by one. 

23. 

UpdateLanding 

Spot 

Listens to Scheduler for failed aircraft and performs the 
following if its assigned landing spot is in the standby list (Ls), 
i.e., waiting for the aircraft to start its next assignment: 

• remove landing spot from the standby list (Lwi), 

• remove landing spot from priority list (Lk) if in the list, 

• decrease number of standby landing spots (NwO by one, 
and 

• trigger FindReplacement event immediately with landing 
spot passed on as argument. 

24. 

ResetLanding 

Spot 

Listens to Scheduler to redeploy the landing spot and performs 
the following: 

• add the load transfer amount (as stored in the landing spot’s 
assignment record) to the remaining load (Qi) for the ship, 

• reset landing spot’s assignment to null, and 

• add landing spot to the available list (Lai) and increase 
number of available landing spots (Nai) by one, and 
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• triggers NeedSupport event immediately after that. 

This event is only applicable when Replacement Mode #1 is 
selected for the simulation. 


Table 25. Events for ShipServer Component 


5. Scheduler Component 

The Seheduler is essentially the overall management system for the fleet 
operation, handling all the tasking and resource allocation activities. The following three 
figures depict the component event graph. The specific events are described in Table 26. 
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Figure 22. Event Graph for Scheduler Component (Part 1) 
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Figure 23. Event Graph for Scheduler Component (Part 2) 
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Figure 24. Event Graph for Scheduler Component (Part 3) 
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1. 

Run 

Performs initialization for the following state variables at 
the start of the simulation: 



• 

initialize assignment list (A) to null, 



• 

initialize aircraft holding list (Ah) to null. 



• 

initialize aircraft holding record (H) to null. 



• 

initialize the list of aircraft requiring support (As) to 
null. 



• 

initialize the list of aircraft waiting for support (Aw) to 
null. 



• 

initialize landing spot replacement list (Lr) to null. 



• 

initialize the support landing spot list (Ls) to null. 



• 

initialize number of support landing spots from ship 
entity with identifier i (Nsi) to zero. 



• 

initialize number of landing spots for ship entity with 
identifier i (NO to zero. 



• 

initialize minimum number of landing spots required to 
for direct airlift operation support for ship entity with 
identifier i (NmO to no. 



• 

initialize remaining quantity of load type 1 for ship 
entity with identifier i (Qi[i]) to zero, and 



• 

initialize remaining quantity of load type 1 for the fleet 
(Q[i]) to zero. 

2. 

UpdateAircraftList 

Listens to AircraftServer instances for aircraft requesting 
new assignment and performs the following: 



• 

create a new entry for the aircraft and set the time-in 
using current time, add it to the holding record (H) and 
set aircraft’s entry accordingly, and 



• 

add aircraft to the holding list (Ah), sorted using 
aircraft’s expected time available for next assignment. 



If Replacement Mode #0 scheme is selected for the 
simulation, the following will be performed: 



• 

the aircraft will be checked against the replacement list 
(Lr) first to determine if there is a landing spot with an 
assigned aircraft of the same type before adding it to 
the holding list. If there is, a new assignment will be 
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created for this aircraft instead, inheriting the assigned 
landing spot and prepared load from the failed aircraft. 
The landing spot is removed from the list (Lr), and 

• UpdateReplacementAircraft and StandbyLoading 
events will be triggered immediately with the aircraft 
and landing spot passed on as argument respectively, 
and 

• AircraftStatus event will also be triggered immediately 
with the landing spot and the aircraft’s availability 
status passed on as argument. 

3. 

UpdateReplacement 

Aircraft 

Does nothing; meant to be heard by AircraftServer 
instances. 

4. 

StandbyLoading 

Does nothing; meant to be heard by AircraftServer and 
ShipServer instances. 

5. 

AircraftStatus 

Does nothing; meant to be heard by ShipServer instances. 

6. 

CreateShip 

Listens to ShipServer instances for the newly created ship 
entities and performs the following: 

• get the entity’s allocated load quantity and update the 
remaining load quantity (Qi[i]) for that ship and the 
remaining load quantity (Qpj) for the fleet, and 

• get the entity’s total landing spots and update the 
number of landing spots (Ni) for that ship. 

7. 

NeedSupport 

Listens to AircraftServer instances for aircraft requiring 
support services and performs the following: 

• set aircraft’s need for refuel or repair indicator to true 
based on the support type required, 

• add aircraft to the need support list (As) if it is not in it, 

• trigger UpdateResources event immediately with the 
aircraft passed on as argument, if repair service is 
required, and 

• trigger SeekSupport event immediately with the aircraft 
passed on as argument, if aircraft is available or waiting 
for load-up. 

8. 

CheckTask 

Listens to ShipServer instances for landing spot checking 
for task and triggers one of the following immediately: 

• CheckSupport event with the landing spot and crew 


94 















S/N 

Event 

Purpose 



size passed on as argument, if there is aircraft requiring 
or waiting for support (Aw), or otherwise 

• CheckLoad event with the landing spot passed on as 
argument, if the holding list (Ah) is not empty and 
crew is available, or otherwise 

• Tasking event with the landing spot and load type 
passed on as argument. The load type is set as “9999” 
to indicate no tasking. 

9. 

CheckSupport 

Checks whether the landing spot is required for support 
service by performing one of the following: 

• if there is aircraft waiting for support (Aw), 

■ trigger either StateRefuel or StartRepair event 

immediately, based on the support type required 
with the aircraft and landing spot passed on as 
argument, 

■ remove aircraft from the need support list (As) if it is 

in it, 

■ decrease the number of support landing spots from its 

ship (Nsi) by one, 

■ trigger Tasking event immediately with the landing 

spot and load type passed on as argument. The load 
type is set as “8888” to indicate a support tasking, or 

• if the support landing spots from its ship has not 
exceeded the individual ship quota (i.e., Nsi < Ni - Nmi) 
and overall list is (Ls) is less than the maximum 
number allowable for the fleet (ns), or there are no 
remaining loads (Qi[i]) left for the ship, 

■ add landing spot to the support list (Ls), 

■ increase the number of support landing spots from its 

ship (Nsi) by one, and 

■ trigger Tasking event immediately with the landing 

spot and load type passed on as argument. The load 
type is set as “8888” for the same reason, or 

• if there is crew available, trigger CheckLoad event with 
the landing spot passed on as argument, or otherwise 

• trigger Tasking event immediately with landing spot 
passed on as argument together with the load type set 
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S/N 

Event 

Purpose 



to “9999” to indicate no tasking. 

10. 

CheckLoad 

Initiates load assignment process by performing one of the 
following: 

• trigger Tasking event immediately with landing spot 
and load type passed on as argument, if there is no 
aircraft in the holding list (Ah) or all loads for that ship 
(Qi[i]) have been transferred. The load type is set as 
“9999” to indicate no tasking, or 

• trigger AllocationModeO or AllocationModel event 
based on the selected for the simulation and pass on 
landing spot as argument. 

11. 

AllocationModeO 

Performs load allocation based on ship-level consideration 
only, as per the discussion in the Design section. 

Triggers Allocate event immediately with landing spot, 
aircraft and load type passed on as argument, if there is a 
match or otherwise, the Tasking event with landing spot 
passed on as argument together with the load type set to 
“9999” to indicate no tasking. 

12. 

AllocationModel 

Performs load allocation based on fleet-level consideration 
only as per the discussion in the Design section. 

Triggers Allocate event immediately with landing spot, 
aircraft and load type passed on as argument, if there is a 
match or otherwise, the Tasking event with landing spot 
passed on as argument together with load type set to 
“9999” to indicate no tasking. 

13. 

Allocate 

Performs load allocation for the landing spot and the 
assigned aircraft as follows: 

• remove aircraft from holding list (Ah), assign landing 
spot as its next landing spot, set time-out for its entry 
record using current time and change its status to one, 

• compute the load transfer amount (j) and update the 
assignment record based on the discussed formula, i.e., 

\Ckl,Qni] > Ckl 
qi = < 

otherwise 

• decrease remaining load left for the ship (Qi[i]) and fleet 
by (Q[i]) the load transfer amount, and 

• trigger Tasking event immediately with the landing 
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S/N 

Event 

Purpose 



spot and load type passed on as argument. 

14. 

Tasking 

Does nothing; meant to be heard by AircraftServer and 
ShipServer instances. 

15. 

StartRefuel 

Does nothing; meant to be heard by AircraftServer 
instances. 

16. 

StartRepair 

Does nothing; meant to be heard by AircraftServer 
instances. 

17. 

SeekSupport 

Listens to AircraftServer instances for returned aircraft 
seeking support and performs one of the following: 

• if there are landing spots in the support list (Ls), 

■ remove landing spot from support list (Ls) and 

decrease number of support landing spots for the 
associated ship (NsO by one, and 

■ trigger either StateRefuel or StartRepair event 

immediately based on the support type required with 
the aircraft and landing spot passed on as argument, 
or otherwise 

• add aircraft to the list awaiting for support (Aw). 

18. 

UpdateResources 

Updates resources due to an aircraft failure by performing 
the following: 

• remove failed aircraft from the holding list (Ah) if it is 
on it, or otherwise, trigger UpdateLandingSpot 
immediately with aircraft passed on as argument, and 

• trigger UpdateFailedAircraft event immediately with 
aircraft passed on as argument. 

19. 

UpdateLandingSpot 

Does nothing; meant to be heard by ShipServer instances. 

20. 

UpdateFailedAircraft 

Does nothing; meant to be heard by AircraftServer 
instances. 

21. 

FindReplacement 

Listens to ShipServer instances for landing spot requiring a 
replacement aircraft and performs one of the following 
based on the simulation mode selected: 

For Renlacement Mode #0 Scheme 

If an aircraft is found in the holding list (Ah) that matches 
the failed aircraft type that the landing spot was previously 
assigned to, 

• remove it from the list and set the time-out for its entry 
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S/N 

Event 

Purpose 



record using current time, 

• create a new assignment pairing up the aircraft and the 
landing spot (that is already loaded), and set the aircraft 
status accordingly, and 

• trigger UpdateReplacementAircraft and 

StandbyLoading events immediately with the aircraft 
and landing spot passed on as argument respectively. 

If there is no matching aircraft in Ah, add landing spot to 
the replacement list (Lr). 

For Renlacement Mode #1 Scheme 

Add the load transfer amount (as stored in the landing 
spot’s assignment record) to the remaining load for the 
affected ship (Qi[i]) as well as the fleet (Q[i]), and trigger 
ResetLandingSpot event immediately with the landing spot 
passed on as argument. 

22. 

ResetLandingSpot 

Does nothing; meant to be heard by ShipServer instances. 

23. 

StandbyLoading 

Does nothing; meant to be heard by ShipServer and 
AircraftServer instances. 


Table 26. Events for Scheduler Component 


In addition, the Scheduler component also has built-in utilities to output the list of 
assignments and the holding record into text files for that simulation run. One can then 
review the details off-line and understand how the operation process has taken place, if 
required. 


6. Recorder Component 

This is more of a peripheral component created solely for recording the following 
runtime data for each simulation run, such as: 

• mission completion time, defined by the time when the last sortie reaches 
the target site to complete the load delivery, and 

• quantity delivered for each of the three load types over the simulation 
duration with user-definable interval for the recording. 
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The data for each individual run is then collected by the main program to support 
the post-simulation statistical analysis. This component also has the built-in utility to 
output the quantity delivered over time to a text file. The following figure depicts the 
component event graph and the specific events are described in Table 27. 


(i <x- I) 



{Tc = 0, 

lc = 0, 


{D[i]|t] - Dp]} 



{qp] = a.getAllocatedLoadO, 
Qt[ii = Qt|]] + qp]} 


Qtpi = 0, 

Dfi] = 0, 
D[i][n = 0 } 



{I = c.getAssignment().getLoadType(), {Tc = Schedule.getSimTimeO, 

q = c.getAssignment().getLoadQuantity(), Ic = 1} 

Dp] = Dp] + q} 


Figure 25. Event Graph for Recorder Component 
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S/N 

Event 

Purpose 

1. 

Run 

Performs the following at the start of the simulation: 

• initialize delivery completion time (Tc) to zero, 

• initialize delivery completion indicator (Ic) to zero, 

• initialize total quantity for load type 1 (Qt[ 1 ]) to zero, 

• initialize quantity delivered to site for load type 1 (D[i]) to 
zero, and 

• create a 1 by x dimensional array for recording the quantity 
delivered for each load type 1 (D[i][t]) at a user-defined time 
interval (ti) over the simulation duration, where 1 is the 
number of load types and x is the number of intervals. 
Initialize the value for each array element to zero, and 

• triggers MeasureLoad event immediately with zero passed 
on as argument, i.e., the counter used for looping the event. 

2. 

CreateShip 

Listens to ShipServer instances for newly created ship entity 
and adds its load quantity to total load (Qt[I])- 

3. 

MeasureLoad 

Updates the appropriate entry for the load quantity delivered 
(D[i][t]) at that instance, increase the counter by one, and 
triggers itself after ti time delay with the counter passed on as 
argument for (x - 1) times. 

4. 

ReachTarget 

Listens to AircraftServer instances for the delivery aircraft and 
increases the load quantity delivered (D[i]) by the load transfer 
amount as stored in the aircraft’s assignment record. 

Triggers CompleteDelivery event immediately if all loads have 
been delivered, by comparing the values between (D[i]) and 
(Qt[I])- 

5. 

CompleteDelivery 

Sets the delivery completion time (Qt[I]) and delivery 
completion indicator (Ic). 


Table 27. Events for Recorder Component 
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V. TESTING AND EVALUATION 


A. OVERVIEW 

The testing of the final airlift model was conducted in two parts. First of all, the 
final model was tested against the verified baseline model to ensure that it can produce 
consistent results when using the same input parameters under a deterministic setting. 
The testing then focused on the general event flow and the variable timing parameters to 
verify that the simulated airlift process abides with the paper’s design. 

B. VERIFICATION AGAINST BASELINE MODEL 
I. Objective 

The objective was to verify that the final airlift model will generate the same load 
transfer capabilities and the sorties as the baseline model for the three Civil Support 
mission scenarios and the respective force structures, such as those performed in Chapter 
ITT and summarized in the following table. 


S/N 

Scenario 

Scenario Severity 

Low 

Mean 

High 

B 

Load Transfer Capability based on Baseline Airlift Model 

1. 

For Cargo (lbs) 

2,286,000 

729,000 

1,318,500 

2. 

For Equipment (sets) 

6 

11 

16 

3. 

For Personnel (pax) 

32 

72 

99 

B. 

Number of Delivery Sorties 

4. 

For CH-53 

67 

30 

56 

5. 

For SH-60 

115 

24 

14 

C. 

Aircraft Quantity (i.e., the force structure) 

6. 

For CH-53 (ea) 

1 

2 

7 

7. 

For SH-60 (ea) 

2 

2 

2 


Table 28. Test Cases for Final Airlift Model against Baseline Model 
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2. Approach 

A similar approach on how the baseline model was verified against Project SEA- 
15 findings was adopted. The same input parameters for the baseline airlift model were 
used for the final model in order for it to generate a deterministic output for comparison 
with the baseline model. The following are the main settings used for the final model: 

• a single ship was modeled to supply all the required loads with a high 
number of logistics crew and landing spots (400 each), 

• average time values were used for the loading, unloading, delivery and 
recovery phase (based on baseline model inputs), with the loading time set 
to zero, 

• the endurance distance (without refueling) and the time-to-failure for the 
aircraft and were set to high values (10,000 nm and 10,000 hr respectively) 
to negate the need for refuel and repair, and 

• reduced operating duration (7.65 hr based on baseline model input) to 
account for the time spent for refuel and repair. 

Given that the final model can generate the list of conducted sorties with the 
involved timings, the approach was to inject a higher load transfer capability value (i.e., 
for cargo load type) as input to the model, so as to show the last sortie that can be 
completed within the mission time and the remaining load at that juncture. In this case, 
the quantity set was set just one more than the load transfer capability, i.e., 2,286,001, 
729,001 and 1,318,501 lbs for the low, mean and high severity scenarios respectively. 

2. Test Results 

For all the three tested scenarios, the final airlift model generated the same load 
transfer capabilities and the required sorties as per the baseline model. The following is 
the extract of the model output for the high severity scenario test case, which showed that 
the 70* sortie was the last one that could be completed within the mission time (before 
459 min, the equivalent of 7.65 hr), and the remaining load at that instance was one 
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pound of cargo, the expected “right” answer for the testing. Refer to Appendix B for the 
complete model output files for the three test scenarios. 


Assign# 

Aircraft# 

Load 

Type# 

Transfer 

Qty 

Start 

Loading 

Time 

Start 

Sortie 

Time 

Reach 

Target 

Time 

Leave 

Target 

Time 

End 

Sortie 

Time 

Cargo 

Left 

Eqpt 

Left 

Passenger 

Left 

#1 

CH53#0 

1 

2 

0 

1 

34 

35 

54.41 

1318501 

14 

99 

#2 

CH53#1 

1 

2 

0 

1 

34 

35 

54.41 

1318501 

12 

99 

#3 

CH53#2 

1 

2 

0 

1 

34 

35 

54.41 

1318501 

10 

99 

#4 

CH53#3 

1 

2 

0 

1 

34 

35 

54.41 

1318501 

8 

99 

#5 

CH53#4 

1 

2 

0 

1 

34 

35 

54.41 

1318501 

6 

99 

#6 

CH53#5 

1 

2 

0 

1 

34 

35 

54.41 

1318501 

4 

99 

#7 

CH53#6 

1 

2 

0 

1 

34 

35 

54.41 

1318501 

2 

99 

#68 

CH53#4 

0 

27000 

380.88 

381.88 

414.88 

415.88 

435.29 

54001 

0 

0 

#69 

CH53#5 

0 

27000 

380.88 

381.88 

414.88 

415.88 

435.29 

27001 

0 

0 

#70 

CH53#6 

0 

27000 

380.88 

381.88 

414.88 

415.88 

435.29 

1 

0 

0 

#71 

SH60#0 

0 

1 

405.89 

406.89 

448.14 

449.14 

471.59 

0 

0 

0 


Figure 26. Extract of the Final Airlift Model Output for High Severity Scenario 

Test Case 


C. VERIFICATION FOR GENERAL EVENT FLOW AND TIMING 

PARAMETERS 

1. Objective 

The testing was to verify that the general event flow and the variable timing 
parameters of the simulated airlift processes are in accordance with the paper design, i.e., 
based on the event graphs and the inputs parameters used. 

2. Approach 

A straightforward testing approach was adopted by running the model with a set 
of input parameters and then verifying the output results using the verbose mode and the 
other generated files (similar to the one presented earlier) to ensure that the logged events 
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have occurred in proper sequence and are reflective of the inputs used. In this case, 
uniform distribution was used for all random timing variates to facilitate verification. For 
each set of input parameters tested, multiple runs (i.e., 1,000) were conducted to verify 
that the random variates used would inject stochasticity into the simulation as well as sift 
out any latent anomalies that may not surface within a single run. 

3. Results 

The model was tested against ten sets of different input parameters. The 
generated event flows and timings were found to be consistent with the design and input 
parameters. 

The verification scope was by no means comprehensive, given the number of 
parameters and their ranges that can be varied to meet different simulation needs. For the 
purpose of this thesis work, the verification conducted and the test results shown were 
deemed adequate to move on and experiment with the model’s capability. 
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VI. DESIGN OF EXPERIMENT 


A. OVERVIEW 

Three sets of experiments were conducted. The first experiment was designed to 
demonstrate the final airlift model’s ability to meet the objectives set for this thesis work 
with the next experiment to illustrate the difference in the outcomes (if any) of using the 
various simulation schemes implemented in the model. The last experiment was 
conducted to compare the load transfer capability computed by the final and baseline 
airlift models. 

B. EXPERIMENT #I - GENERAL PERFORMANCE MEASURES 

1. Objectives 

The experiment was designed to demonstrate that the final airlift model can 
support the list of performance measures established under Chapter II for assessing the 
airlift operation effectiveness and its workflow efficiency. 

2. Experiment Setting and Input Parameters 

The high severity scenario defined for the Civil Support mission was used as the 
backdrop for the experiment to assess the airlift operation performance of the 
recommended Phase Zero force. In a nutshell, three ships, i.e., JMSDF, LPD-17 and 
JHSV with seven CH-53 and two SH-60 are required to airlift 1,238,200 lbs of cargo, 16 
sets of equipment and 99 passengers to an affected area that is 55 nm away from the ships 
within the mission day (i.e., 12-hour operation day). The input parameters adopted those 
used or referenced in Project SEA-15 or otherwise, were based on notional values. Refer 
to Appendix C for the model input parameters defined for this experiment. 

The airlift model was run 1,000 times to gather a good statistical estimate for the 
performance measures. 
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3. 


Simulation Outcome 


The main performance measures captured for the simulation are summarized in 
the following table. 


S/N 

Parameters 

Value 

B 

Overall Measures 

1. 

Average cargo delivered (lbs) 

1,238,200(100%) 

2. 

Average equipment delivered (sets) 

16 (100%) 

3. 

Average passengers delivered (pax) 

99 (100%) 

4. 

Average time to complete delivery (hrs) 

8.11 hrs 

5. 

Minimum time to complete delivery (hrs) 

7.24 hrs 

6. 

Maximum time to complete delivery (hrs) 

10.45 hrs 

7. 

Standard deviation for delivery time (hrs) 

0.48 hrs 

8. 

Number of completed delivery 

1000(100%) 

B. 

Ship-related Measures 

JMSDF 

LPD-17 

JHSV 

9. 

Average cargo remaining (lbs) 

0 

0 

0 

10. 

Average equipment remaining (sets) 

0 

0 

0 

11. 

Average passengers remaining (pax) 

0 

0 

0 

12. 

Crew utilization 

16.39% 

22.12% 

26.41% 

13. 

Landing spots utilization 

71.96% 

63.43% 

58.89% 


• Active preparation/loading activities 

16.39% 

22.12% 

26.41% 


• Standby for load-up 

13.58% 

16.62% 

24.69% 


• Service support 

41.98% 

24.69% 

6.30% 

C. 

Aircraft-related Measures 

CH-53 


SH-60 

14. 

Average cargo delivered (lbs) 

1,209,669 (97.7%) 

28,531 (2.3%) 

15. 

Average equipment delivered (sets) 

16 (100%) 

0 (0%) 

16. 

Average passengers delivered (pax) 

6.9 (7%) 

92.1 (93%) 

17. 

Average sorties flown 

54.7 

14.5 

18. 

Aircraft utilization 

64.5% 

66.7% 


106 
















































S/N 

Parameters 

Value 


• Waiting 

2.57% 

2.51% 


• Loading 

1.13% 

3.25% 


• Delivery 

35.70% 

30.90% 


• Unloading 

1.13% 

3.26% 


• Recovery 

21.08% 

22.71% 


• Refuel 

1.77% 

1.20% 


• Repair 

3.10% 

2.86% 


Table 29. Performance Measures for Final Airlift Operation Model 


The experiment has demonstrated the model’s ability to support the defined 
performance measures for operational/tactical level analysis with the higher resolution 
modeling of the airlift operation process using DBS. To illustrate, based on the 
assumptions and input parameters used, the model suggested that the recommended 
Phase Zero force would be able to support the high severity scenario with the following 
findings that can be drawn from the data collected: 

• Mission Completion Time . The mission duration, on average, would last 
for 8.1 hrs with 95% confidence that the mission can be completed within 
8.9 hrs based on the standard deviation observed (and through further 
statistical analysis). 

• Mission Sorties . It would take about 70 sorties to complete the delivery 
where each CH-53 and SH-60 aircraft accounts for 7.8 and 7.25 sorties on 
average respectively. In this case, the higher sortie rate for CH-53 is 
largely attributed to its faster airspeed. 

• Aircraft Utilization . The CH-53 and SH-60 aircraft would be utilized 
about two-thirds of the time, on average. There would be some waiting 
expected for the required resources to execute the load-up and/or provide 
the service support at times. Longer loading/unloading time for SH-60 


107 




















aircraft would also be expected by virtue of the fact that it will be used 
more often for transporting passengers, due to its relative advantage in 
doing so as discussed earlier. 

• Landing Spot Utilization . The utilization rate is dependent upon the 
amount of loads and the number of landing spots onboard the ship. The 
gathered data can facilitate the planning of the load distribution based on 
the resources available for each ship. For this experiment, the load 
distribution seemed reasonable, with an overall utilization rate difference 
of less than 10% off the average. The higher usage rates for service 
support observed for JMSDF and LPD-17 are because more landing spots 
were set aside for that purpose, especially for the JMSDF. For JHSV, 
there is only one landing spot and it was therefore set up to do load 
transfer full time until all the loads had been transferred, before providing 
service support. 

• Crew Utilization . Similarly, crew utilization is dependent upon the 
amount of loads to be transferred and in this case, the JHSV has a higher 
utilization for the reason cited above. 

• Duration of Aircraft in Various Operation Phases . The gathered data 
provided an indication of the expected time spent for each aircraft type in 
each of the operation phases. With good data on the mean-time-between- 
failure (MTBF) and mean-time-to-repair (MTTR) for the aircraft, the 
simulation would be able to provide a good indication on the overall Ao for 
the aircraft fleet based on the ship resource support/constraint. 

• Load Delivered Over Time . In order to determine the load “arrival” rates, 
at the target site, for planning the supporting and follow-on ground 
activities, the model also generates the transferred load quantity over the 
mission duration based on the timing resolution that one is interested in 
monitoring. The following figure is the load-versus-time graph plotted. 
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based on the data eolleeted for experiment. In this ease, the time interval 
was set at six minutes, and the delivered quantity presented in pereentages, 
with referenee to load transfer requirements. 
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Figure 27. Load Delivered Over Time for High Severity Seenario 
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c. 


EXPERIMENT #2 - COMPARISON OF SIMULATION SCHEMES 


I. Objectives 


The experiment was designed to compare the simulation outcomes of using the 
different load allocation and landing spot reassignment schemes that were implemented 
in the model. To recap, the available modes are 


• Load Allocation Mode #0 (LAM#0) . The load allocation is optimised at 
the ship-level. 

• Load Allocation Mode #1 (LAM#1) . The load allocation optimization is 
attempted at the fleet-level based on a longer waiting time (set as five 
minutes) that one is willing to accept in order to get a better load-aircraft 
match, based on the list of aircraft that have requested assignments at the 
juncture. 

• Landing Spot Reassignment Mode #0 (LRM#0) . This is the substitution 
mode whereby the landing spot with assigned aircraft that have failed will 
find the next available replacement of the same aircraft type to takeover 
the prepared load. 

• Landing Spot Reassignment Mode #1 (LRM#1) . This is the reset mode 
whereby the landing spot will “return” the prepared load and check for the 
next task instead. 


2. Experiment Setting and Input Parameters 

The same high severity scenario and input parameters were used as baselines for 
this experiment, except for the load allocation and landing spot reassignment modes 
selected. Four sets of scenarios were simulated using the different combinations for the 
two modes available. Each set of scenarios was run 1,000 times to gather a good sample 
size for comparison. 


no 



3. 


Simulation Outcome 


All loads can be delivered within the mission time for the all sehemes 
implemented. The following table summarizes the key performance measures recorded 
for these four sets of simulated seenarios. 


Parameters 

LAM#0 

LAM#1 

LRM#0 

LRM#1 

LRM#0 

LRM#1 

Overall Parameters 


Average time to complete 
delivery (hrs) 

8.15 

8.13 

8.11 

8.11 

Minimum time to complete 
delivery (hrs) 

7.25 

7.18 

7.17 

7.24 

Maximum time to complete 
delivery (hrs) 

11.61 

11.38 

10.84 

10.45 

Standard deviation for delivery 
time (hrs) 

0.53 

0.50 

0.48 

0.48 

Ship-related Measures 


Average erew utilization 

20.95% 

21.39% 

21.17% 

21.64% 

Average landing spots utilization 

64.69% 

64.94% 

64.67% 

64.48% 

• Aetive preparation/loading 
activities 

20.95% 

21.39% 

21.17% 

21.64% 

• Standby for load-up 

19.16% 

18.46% 

19.36% 

18.79% 

• Service support 

24.52% 

25.09% 

24.10% 

24.33% 

Aircraft-related Measures 


Cargo delivered by CH-53 (lbs) 

1,208,066 

1,208,113 

1,210,103 

1,209,669 

Cargo delivered by SH-60 (lbs) 

30,134 

30,087 

28,097 

28,531 

Equipment delivered by CH-53 
(sets) 

16 

16 

16 

16 

Equipment delivered by SH-60 
(sets) 

0 

0 

0 

0 

Passengers delivered by CH-53 
(pax) 

12.33 

11.76 

6.696 

6.909 
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Parameters 

LAM#0 

LAM#1 

LRM#0 

LRM#1 

LRM#0 

LRM#1 

Passengers delivered by SH-60 
(pax) 

86.67 

87.24 

92.304 

92.091 

Sorties flown by CH-53 

54.93 

54.95 

54.72 

54.73 

Sorties flown by SH-60 

14.19 

14.22 

14.38 

14.46 

Average Aircraft utilization 

67.27% 

66.70% 

67.18% 

66.59% 

• Waiting 

3.16% 

2.59% 

3.14% 

2.54% 

• Loading 

2.11% 

2.11% 

2.19% 

2.19% 

• Delivery 

33.36% 

33.38% 

33.18% 

33.30% 

• Unloading 

2.11% 

2.11% 

2.19% 

2.19% 

• Recovery 

21.72% 

21.74% 

21.82% 

21.90% 

• Refuel 

1.46% 

1.47% 

1.49% 

1.49% 

• Repair 

3.37% 

3.29% 

3.17% 

2.98% 


Table 30. Comparison Between Different Simulation Schemes Implemented in Final Airlift 

Model 

Based on the gathered data, the average and maximum delivery completion times 
for both scenarios, using the fleet-level load allocation (i.e., LAM#1) were shorter, but of 
no significant difference. In fact, the overall performance profiles for the task force 
under these various schemes were found to be very similar except for the specific areas 
where the implemented schemes have a direct effect. Under the fleet-level load 
allocation scheme, there was a better load-aircraft match observed than expected, with 
more than a 5% increase in passengers being transported by SH-60 aircraft. As for the 
landing spot reassignment scheme, the landing spot usage for preparation/loading 
activities was observed to be slightly higher and correspondingly less time was spent 
standing-by for aircraft under both scenarios using the reset approach (i.e., LRM#1), 
which is to be expected. However, the secondary effect on the waiting time, which was 
found to be shorter (i.e., >20%), under the reset approach, was not something perceivable 
at the design stage. 
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D. EXPERIMENT #3 - LOAD TRANSFER CAPABILITY 


1. Objectives 

The experiment was conducted to assess the load transfer capability of the Phase 
Zero task force to support the high severity scenario based on the stochastic approach, 
using the final airlift model, and compare the results from the baseline model, which was 
deterministic based. 

2. Experiment Setting and Input Parameters 

The scenario input parameters were the same as those used for the first 
experiment, except that the cargo load quantity was increased to 2.5M lbs as a “goal” to 
assess how much the task force could transfer within the 12-hour mission day. Transfer 
capability for cargo load type was used for the experiment because it was the benchmark 
adopted by Project SEA-15 for the same purpose. 

3. Simulation Outcome 

The performance measures captured for the simulation are summarized in the 
following table with the “load delivered over time” graph depicted in Figure 28. 


S/N 

Parameters 

Value 

n 

Overall Measures 

Min 

Mean 

Max 

1. 

Cargo delivered (lbs) 

1,697,000 

2,049,000 

2,242,000 

2. 

Equipment delivered (sets) 

16 

16 

16 

3. 

Passengers delivered (pax) 

96 

99 

99 

B. 

Ship-related Measures 

JMSDF 

LPD-I7 

JHSV 

4. 

Cargo allocated (lbs) 

1,000,000 

1,000,000 

500,000 

5. 

Cargo remaining (lbs) 

11,526 

283,438 

7,974 

6. 

Equipment allocated (sets) 

6 

6 

4 

7. 

Equipment remaining (sets) 

0 

0 

0 

8. 

Passengers allocated (pax) 

63 

24 

12 

9. 

Passengers remaining (pax) 

0 

0 

0 
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S/N 

Parameters 

Value 

10. 

Crew utilization 

25.50% 

36.63% 

52.71% 

11. 

Landing spots utilization 

94.03% 

96.79% 

97.11% 


• Active preparation/loading activities 

25.50% 

36.63% 

52.71% 


• Standby for load-up 

22.23% 

26.68% 

40.68% 


• Service support 

46.30% 

40.68% 

3.72% 

c. 

Aircraft-related Measures 

CH-53 


SH-60 

12. 

Average cargo delivered (lbs) 

1,994,291 

54,340 

13. 

Average equipment delivered (sets) 

16 

0 

14. 

Average passengers delivered (pax) 

0 

99 

15. 

Average sorties flown 

86.0 

22.2 

16. 

Aircraft utilization 

99.70% 

99.53% 


• Waiting 

3.34% 

2.90% 


• Loading 

1.17% 

4.04% 


• Delivery 

55.13% 

50.32% 


• Unloading 

1.63% 

3.96% 


• Recovery 

31.29% 

32.69% 


• Refuel 

2.63% 

1.67% 


• Repair 

3.97% 

3.95% 


Table 31. Load Transfer Capability for High Severity Scenario based on Final Airlift Model 

The data gathered from the final airlift model suggested that the load transfer 
capability for Phase Zero force is, on average, about two million lbs for cargo. It met the 
equipment and passengers transfer requirements on most occasions, except for one 
instance where an additional sortie was required to complete passenger delivery. If this is 
disregarded, there is 95% confidence that the task force can deliver 2.18M lbs of cargo 
based on the observed standard of about 80K lbs. 
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Figure 28. Load Transfer Capability over Time for High Severity Scenario based on 

Final Airlift Model 


The average load transfer capability, based on this final airlift model, is 
substantially higher (>65%) than that obtained from the baseline model, i.e., 1,318,500 
lbs. This vast difference is largely attributed to the assumptions made in deriving the 
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effective operating hours. For the baseline model (and in the case of Project SEA-15), a 
three-hour block was set aside for refueling and other overheads with the further 
assumption of an 85% Ao, which resulted in the 7.65 effective operating hours for the 
mission day. For the final model, the settings for the meantime for refueling was five 
minutes, meantime for preparing cargo/equipment at 15 minutes and for passengers at 
five minutes, with MTBF and MTTR at 20-hours and 1-hour respectively (giving an 
equivalent Ao of about 95.2%) for both aircraft types. Based on the gathered aircraft 
utilization data in Table 31, the equivalent effective operating hours can be approximated 
by discounting the average time spent for each aircraft in the waiting, refueling and repair 
phases. This value worked out to be 10.85 hours, i.e., at least three hours more than what 
the other approach used. 

To further illustrate the Aq impact on the load transfer capability, additional 
simulations were conducted with MTBF inputs ranging between 10 to 20 hours using a 
2.5-hour time block and MTTR inputs between one to three hours with a 1-hour time 
block. Table 32 summarizes the computed Ao (based on MTBF and MTTR), observed 
effective operating hours, and the average load transfer capability for cargo for each of 
the scenarios (with 1,000 simulation runs each). Again, for most of the simulation runs, 
the delivery of passengers and equipment were complete. Figure 29 depicts the average 
load transfer capability trend over the tested ranges for MTTR and MTBF using linear 
interpolation based on the sampled points. 
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MTBF 

(hr) 

MTTR 

(hr) 

A„ 

Effective Operating 
Hours (hr) 

Transfer Capability for 
Cargo (lbs) 

10 

1 

0.91 

10.31 

1,932,883 

10 

2 

0.83 

9.64 

1,777,221 

10 

3 

0.77 

9.21 

1,681,635 

12.5 

1 

0.93 

10.65 

1,974,621 

12.5 

2 

0.86 

10.15 

1,898,456 

12.5 

3 

0.81 

9.78 

1,815,096 

15 

1 

0.94 

10.65 

2,006,324 

15 

2 

0.88 

10.15 

1,898,456 

15 

3 

0.83 

9.78 

1,815,096 

17.5 

1 

0.95 

10.76 

2,027,820 

17.5 

2 

0.90 

10.32 

1,932,200 

17.5 

3 

0.85 

10.02 

1,867,651 

20 

1 

0.95 

10.85 

2,048,631 

20 

2 

0.91 

10.47 

1,968,564 

20 

3 

0.87 

10.16 

1,899,240 


Table 32. Operational Availability Impact on Load Transfer Capability for High Severity 

Scenario based on Final Airlift Model 
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MTBF (in hours) 

Figure 29. MTTR and MTBF impacts on Load Transfer Capability for High Severity 

Scenario based on Final Airlift Model 

The simulation results still show a higher load transfer capability for the task 
force versus the deterministic approach for MTTR and MTBF ranges tested. For the 
“worst-case” scenario, with MTBF and MTTR set at 10-hours and 3-hours respectively, 
i.e., giving a lower 77% Ao than the 85% used for the baseline model, the average load 
transfer capability is still higher, at about 1.68M lbs and 27% more than the deterministic 
value. 
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VII. CONCLUSION 


A. CONCLUSION 

The objectives of this thesis were achieved with the successful implementation of 
a stochastic, dynamic model using DBS that can be used to analyze the airlift operation 
performance of the naval force structure recommended by Project SEA-15 at the 
operational/tactical level. 

An iterative development approach was adopted to allow a baseline model to be 
developed quickly in the early study phase, which demonstrated the feasibility of using 
DES to address the issues under study. The simulated results from the constructed 
baseline model were compared with Project SEA-15 findings, which sifted out some 
inconsistencies in the latter’s reported data. Mathematical and linear optimization 
analyses were conducted as part of the verification process. The baseline model was 
subsequently used to generate the load transfer capability of the Phase Zero force, based 
on the same deterministic input parameters used by the project to serve as a proxy for 
comparison with the final model. The airlift operation was abstracted in the final model 
as a six-phase stochastic process with a scheduler responsible for planning and 
coordinating the activities involved 

Three sets of experiments were conducted, with the first one set up to demonstrate 
the final airlift model’s ability to meet the performance measures using the high severity 
scenario requirement as the case study. The experiment showed that the airlift mission 
could be accomplished within nine hours, with more than 95% confidence, and utilizing 
about 66% of the airlift fleet capacity for a mission day. Eurther experiments were 
conducted to assess the effectiveness of the different load allocation and landing spot 
reassignment (in the event of an assigned aircraft failure) schemes implemented in the 
model, and there were no significant performance differences observed. The final 
experiment, using the final airlift model (i.e., with stochastic data), suggested a much 
higher load transfer capability (>60%) for the Phase Zero force as compared to the 
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baseline model, which was deterministic based. Further data were also collected to 
illustrate the collective impact of the aircraft MTBF and MTTR on the Phase Zero force’s 
load transfer capability. 

B. RECOMMENDATIONS AND FUTURE WORK 

This thesis work has demonstrated the model’s potential in assessing the Phase 
Zero force’s airlift capability by providing operational/tactical level insights to the 
operation process. It should be considered for supporting future analysis work for the 
Phase Zero force if the stakeholders intend to bring the project to the next phase. 

The model was developed primarily as a proof-of-concept, and as such, it did not 
cover all aspects of the airlift operation and/or the depths necessary to support full 
analysis work. With the Phase Zero force being the primary design focus, some aspects 
of the model were implemented specifically (e.g., hard-coded) to that task force. Hence, 
its immediate use for supporting other analysis work of a similar nature is limited. 
However, with the component-based framework adopted for the model, components can 
be readily added /replaced to expand the modeling scope or enhance the model fidelity to 
address these needs, as and when required. The following are possible future 
enhancements of the model’s capability: 

• There were no intermediate delivery requirements/conditions simulated in 
the model, e.g., the different load types must be delivered in sequence, or 
50% of the equipment must be delivered first, before passengers can be 
delivered, etc., because there were no specifications for that based on the 
Project SEA-15 report. The model currently allocates the load based on 
what the aircraft is best suited for, which is reasonable, but there may be 
other overarching requirements, at times, that need to supersede that. 
Incorporating a utility to handle these additional delivery conditions will 
improve the model’s robustness. 

• The maintenance and logistics support for the aircraft, in terms of the 
required repair/refueling facilities and support crew, were not explicitly 
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modeled. Modeling these elements would provide more complete 
shipboard operation coverage and assess its impact on the airlift capability. 

• The load delivery was modeled one-way, i.e., from the ship to the affected 
area, based on the mission scenarios defined for Phase Zero force. 
Expanding the model to cater to two-way delivery would be useful given 
that relief missions would include the need to evacuate affected personnel 
from disaster-hit sites. 

• The airlift operation was modeled as a single continuous process (per 
simulation run), meant for analyzing the performance for a single-day (in 
the case of Project SEA-15) or 24/7 type of missions. Expanding the 
model’s capability to simulate the operation as a “piecewise” continuous 
process, by retaining certain entities’ state information at the break-points, 
would enable it to better mimic non-continuous multi-day missions (e.g., 
simulating daylight operation only). 

• The setting up of a scenario is currently done within the NetBeans IDE and 
the interface may not necessarily be intuitive to a non-programmer. 
Providing a user-friendly front-end user interface would help to improve 
its usability. 

• Parameterize or encapsulate the platform-specific built-in (hardcoded) 
logics into subcomponents to generalize the model so that it could be used 
to support other force structure studies as well. 
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APPENDIX A. PLATFORM CAPABILITIES 


The capabilities for the various platforms are based on the data sheets compiled in 
the Project SEA-15 report [1] except for the JMSDF DDH class destroyer and RQ-8 
Firescout, which the cited report did not have the data sheet for, and in this case, the open 
source data is used. 


A. JMSDF DDH CLASS DESTROYER 


S/N 

Parameters 

Description 

1. 

Displacement (tonnes) 

13,500 standard; 18,000 full load 

2. 

Dimensions (ft) 

646.3 X 108.3 x31.8 

3. 

Main machinery 

COGAG; four EM 2500 gas turbines; two shafts 

4. 

Speed (knts) 

30 

5. 

Range (nm) 

6,000 at 20 kt 

6. 

Missiles 

Raytheon Sea Sparrow RIM-162 ESSM; Eockheed 
Martin Marietta Mk 41 Mod 5 sixteen cell vertical 
launcher 

7. 

Guns 

Two GE 20 mm/76 Sea Vulcan 20, 2-12.7 mm 

MGs 

8. 

Torpedoes: 

6-324 mm (2 triple) HOS-303 tubes 

9. 

Countermeasures: Decoys: 

4 Hycor Mk 137 sextuple RBOC chaff launchers. 

10. 

Electronics Support 

Measures / Electronic 
Countermeasures: 

NOEQ-3C 

11. 

Combat Data Systems: 

Fink 16 

12. 

Radars 

Melco FCS-3; G/H/I-band 

13. 

Navigation 

JRC OPS-20C; I-band. 

14. 

Sonars 

Bow-mounted sonar. OQQ 21. 

15. 

Organic Aircraft 

Three SH-60K plus seven SH-60K or seven MCH- 
101. 


Table 33. Data Sheet for JMSDF DDH (after [18]) 
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B. LPD-17 CLASS AMPHIBIOUS ASSAULT SUPPORT VESSEL 


S/N 

Parameters 

Description 

1. 

Displaeement (tonnes) 

24,900 

2. 

Draft (ft) 

23 

3. 

Enduranee (nm) 

8,000 

4. 

Speed (knts) 

25 

5. 

Offieers 

24 

6. 

Enlisted 

333 

7. 

Troops 

720 

8. 

Organie Boats 

Two ECPE, one RHIB (7m), one utility boat 

9. 

Well Deck Capability 

188ft long x50ft wide x 31ft high 

Two ECAC, or one ECU 1610 plus 14 EEV 

10. 

Cargo Capacity (ft^) 

30,000 

11. 

Vehicle Space (ft"^) 

25,000 

12. 

Water Purification capability 
(gal/day) 

60,000 

13. 

Helo Capable 

Yes 

14. 

Help Spots 

Two CH-53 Spot/ Six extended spots 

15. 

Organic Aircraft 

Two CH-53s, or Eour AH/UH-ls, or Eour CH-46s, 
or Two MV-22s, or One AV-8B Harrier 

16. 

Operating Rooms 

Two 

17. 

Beds 

24 Bed Ward 

18. 

Dental Eacilities 

Yes 

19. 

Self Defense Weapons 

Two MK-49 RAM, two MK-38 Bushmaster, two 
MK-26 12.7mm machine guns 

20. 

Offensive Weapons 

N/A 

21. 

Radar 

SPS-48E Air search, SPS-73 Navigation/Surface 
search 

22. 

Sonar 

N/A 

23. 

Electronic Warfare / Intel 

SEQ-32, SEQ-25A, SRS-1 Joint Services Imagery 
Processing System-Navy (JSIPS-N) 

24. 

Communications 

SHP,UHP,HP,VHP 

25. 

Command/Elag Space 

N/A 


Table 34. Data Sheet for LPD-17 (after [1]) 
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C. JOINT HIGH SPEED VESSEL (JHSV) 


S/N 

Parameters 

Description 

1. 

Displacement (tonnes) 

1463.6 

2. 

Draft (ft) 

11 

3. 

Endurance (nm) 

3,500 

4. 

Speed (knts) 

45 

5. 

Crew 

40 

6. 

Troops 

107+87 

7. 

Organic Boats 

Two RHIB 

8. 

Well Deck Capability 

No 

9. 

Cargo/Vehicle Capacity (ft^) 

28,740 

10. 

Helo Capable 

Yes 

11. 

Help Spots 

Two (MH-60) 

12. 

Organic Aircraft 

N/A 

13. 

Operating Rooms 

One (foldable operating table) 

14. 

Beds 

N/A 

15. 

Dental Facilities 

N/A 

16. 

Self Defense Weapons 

N/A 

17. 

Offensive Weapons 

Mk 96 Stabilized Weapon System, (25mm 
Bushmaster Cannon &Mk 19 40mm Grenade 
Eauncher); Mk 45 40mm Grenade Eauncher 
System 

18. 

Radar Type 

Assumed to include equivalent systems as 
current Mine Warfare surface vessels and 
Eittoral Combat Ships (ECS) 

19. 

Sonar 

20. 

Electronic Warfare / Intel 

21. 

Communications 

HF/UHF/VHF 

22. 

Command/Flag Space 

Two Conference Room, two Staff Rooms 


Table 35. Data Sheet for JHSV (after [1]) 
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D. VISBY CLASS CORVETTE 


S/N 

Parameters 

Description 

1. 

Displacement (tonnes) 

600 

2. 

Draft (Ft) 

7.5 

3. 

Endurance (nm) 

2,300 

4. 

Speed (knts) 

35 

5. 

Crew 

43 (total) 

6. 

Troops 

N/A 

7. 

Organic Boats 

N/A 

8. 

Well Deck Capability 

N/A 

9. 

Cargo Capacity (ft^) 

N/A 

10. 

Vehicle Space (fO^) 

N/A 

11. 

Helo Capable 

One 

12. 

Help Spots 

One 

13. 

Organic Aircraft 

N/A 

14. 

Operating Rooms 

N/A 

15. 

Beds 

N/A 

16. 

Dental Facilities 

N/A 

17. 

Self Defense Weapons 

Umkhonto (Air Defense Missile) 

18. 

Offensive Weapons 

Saab Bofors Dynamics RBS 15 Mk2/MK3, 
Anti-Ship Missile, 

Saab 40mm Grenade Eaunchers, 

Saab Underwater Systems Tp 45 Torpedo, 
Saab Underwater Systems Tp 45 Torpedo 
and Bofors 57mm 70 SAK MK3 GPMG 

19. 

Radar Type 

SaabTech CEROS 200 / Fire Control, 

Saab Sea Giraffe AMB / Air Search, 
Celsius Tech Pilot I-band Surface Seareh and 
CEROS 200 MK3 I/J-band Fire Control 
Radar 

20. 

Sonar 

Hydra Multi-Sonar Suite 

21. 

EW / Intel 

CS-3701 TRSS, MASS Decoy System 

22. 

Communieations 

CETRIS C3 

23. 

Command/Flag Spaee 

N/A 
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S/N 

Parameters 

Description 

24. 

Special Features (e.g. Mission 
Modules) 

ASW, AS, MCM mission modules 


Table 36. Data Sheet for Visby (after [1]) 


E. M-80 STILETTO 


S/N 

Parameters 

Description 

1. 

Displacement (tonnes) 

45 

2. 

Draft (ft) 

Three 

3. 

Endurance (nm) 

500 

4. 

Speed (knts) 

50 

5. 

Officers 

0 

6. 

Enlisted 

Three 

7. 

Troops 

Up to 12 

8. 

Organic Boats 

llmRHIB 

9. 

Well Deck Capability 

N/A 

10. 

Cargo Capacity (ft^) 

Internal capacity for troops and equipment 

11. 

Vehicle Space (ft^) 

N/A 

12. 

Helo Capable 

No 

13. 

Help Spots 

N/A 

14. 

Organic Aircraft 

Small UAV capable landing pad 

15. 

Operating Rooms 

N/A 

16. 

Beds 

N/A 

17. 

Dental Facilities 

N/A 

18. 

Self Defense Weapons 

Currently none, however, space provisions 
have been made for future weapons 

19. 

Offensive Weapons 

Currently none, however, space provisions 
have been made for future weapons 

20. 

Radar 

Navigation Radar 

21. 

Sonar 

N/A 

22. 

Electronic Warfare / Intel 

Currently none, however, space provisions 
have been made for future systems 
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S/N 

Parameters 

Description 

23. 

Communications 

Space provisions have been made for future 
systems 

24. 

Command/Flag Space 

N/A 


Table 37. Data Sheet for M-80 Stiletto (after [1]) 


F. CH-53K SEA STALLION 


S/N 

Parameters 

Description 

1. 

Max Range (nm one way) 

454 

2. 

Cruise Airspeed (kts) 

170 

3. 

Max Airspeed (kts) 

190 

4. 

Speed with external load (kts) 

100 

5. 

Inflight Refueling 

Yes 

6. 

Max Gross Wt (lbs) 

84,700 

7. 

Cargo Lift Capability (lbs) 

36,000 

8. 

External Lift Capability (lbs) 

36,000 

9. 

Normal sling lift (lbs) 

27,000 

10. 

Number of passengers 

55 

11. 

Surface Radar 

No 

12. 

Air Radar 

No 

13. 

SAR/ISAR 

No 

14. 

Airborne Mine Counter-measures 

Yes 

15. 

Forward-Looking Infrared (FLIR) 

Yes 

16. 

Electronic Warfare / Electronics 
Support Measures 

Yes 

17. 

Sonobouys 

No 

18. 

Dipping Sonar 

No 


Table 38. Data Sheet for CH-53K Sea Stallion (after [1]) 
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G. SH-60S SEAHAWK 


S/N 

Parameters 

Description 

1. 

Max Range (nm one way) 

200 

2. 

Cruise Airspeed (kts) 

147 

3. 

Max Airspeed (kts) 

180 

4. 

Speed with external load (kts) 

80 

5. 

Inflight Refueling 

No 

6. 

Max Gross Wt (lbs) 

22,000 

7. 

Cargo Lift Capability (lbs) 

8,000 

8. 

External Lift Capability (lbs) 

6,000 

9. 

Normal sling lift (lbs) 

4,500 

10. 

Number of passengers 

12 

11. 

Surfaee Radar 

No 

12. 

Air Radar 

No 

13. 

SAR/ISAR 

No 

14. 

Airborne Mine Counter-measures 

Yes 

15. 

Forward-Looking Infrared (FLIR) 

Yes 

16. 

Electronie Warfare / Eleetronics 
Support Measures 

No 

17. 

Sonobouys 

No 

18. 

Dipping Sonar 

No 


Table 39. Data Sheet for SH-60S Seahawk (after [1]) 

H. 

RQ-8 FIRESCOUT UAV 


S/N 

Parameters 

Description 

1. 

Length (m) 

6.98 

2. 

Rotor diameter (m) 

8.38 

3. 

Height (m) 

2.87 

4. 

Weight (kg) 

max: 1200 ; empty: 661 

5. 

Speed (km/h) 

231 
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S/N 

Parameters 

Description 

6. 

Ceiling (m) 

6,100 

7. 

Endurance (hours) 

Five 

8. 

Propulsion 

Rolls-Royce/Allison 250-C20W turboshaft; 
310 kW (420 shp) 

9. 

Length (m) 

6.98 


Table 40. Data Sheet for RQ-8 Firescout UAV (after [19]) 
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APPENDIX B. FINAL AIRLIFT MODEL OUTPUT FOR CIVIL 
SUPPORT MISSION TEST CASES 


The following is the output generated by the final airlift model against the three 
Civil Support mission scenario test cases. Each list describes the sorties flown with 
details on the aircraft involved, load type and transferred quantity, event timings and the 
remaining load left after that sortie assignment. 

A. MODEL OUTPUT FROM LOW SEVERITY SCENARIO TEST CASE 


Assign# 

Aircraft# 

Load 

Type# 

Transfer 

Qty 

Start 

Loading 

Time 

Start 

Sortie 

Time 

Reach 

Target 

Time 

Leave 

Target 

Time 

End 

Sortie 

Time 

Cargo 

Left 

Eqpt 

Left 

Passenger 

Left 

#1 

CH53#0 

1 

2 

0 

1 

4 

5 

6.76 

2232001 

4 

32 

#2 

SH60#0 

2 

12 

0 

5 

7.04 

12.04 

14.08 

2232001 

4 

20 

#3 

SH60#1 

2 

12 

0 

5 

7.04 

12.04 

14.08 

2232001 

4 

8 

#4 

CH53#0 

1 

2 

6.76 

7.76 

10.76 

11.76 

13.53 

2232001 

2 

8 

#5 

SH60#0 

2 

8 

14.08 

19.08 

21.12 

26.12 

28.16 

2232001 

2 

0 

#6 

SH60#1 

0 

4500 

14.08 

15.08 

18.83 

19.83 

21.87 

2227501 

2 

0 

#7 

CH53#0 

1 

2 

13.53 

14.53 

17.53 

18.53 

20.29 

2227501 

0 

0 

#8 

CH53#0 

0 

27000 

20.29 

21.29 

24.29 

25.29 

27.06 

2200501 

0 

0 

#9 

SH60#1 

0 

4500 

21.87 

22.87 

26.62 

27.62 

29.66 

2196001 

0 

0 

#10 

SH60#0 

0 

4500 

28.16 

29.16 

32.91 

33.91 

35.95 

2191501 

0 

0 

#11 

CH53#0 

0 

27000 

27.06 

28.06 

31.06 

32.06 

33.82 

2164501 

0 

0 

#12 

SH60#1 

0 

4500 

29.66 

30.66 

34.41 

35.41 

37.45 

2160001 

0 

0 

#13 

CH53#0 

0 

27000 

33.82 

34.82 

37.82 

38.82 

40.59 

2133001 

0 

0 

#14 

SH60#0 

0 

4500 

35.95 

36.95 

40.7 

41.7 

43.74 

2128501 

0 

0 

#15 

SH60#1 

0 

4500 

37.45 

38.45 

42.2 

43.2 

45.24 

2124001 

0 

0 

#16 

CH53#0 

0 

27000 

40.59 

41.59 

44.59 

45.59 

47.35 

2097001 

0 

0 

#17 

SH60#0 

0 

4500 

43.74 

44.74 

48.49 

49.49 

51.54 

2092501 

0 

0 

#18 

SH60#1 

0 

4500 

45.24 

46.24 

49.99 

50.99 

53.04 

2088001 

0 

0 

#19 

CH53#0 

0 

27000 

47.35 

48.35 

51.35 

52.35 

54.12 

2061001 

0 

0 

#20 

SH60#0 

0 

4500 

51.54 

52.54 

56.29 

57.29 

59.33 

2056501 

0 

0 

#21 

SH60#1 

0 

4500 

53.04 

54.04 

57.79 

58.79 

60.83 

2052001 

0 

0 

#22 

CH53#0 

0 

27000 

54.12 

55.12 

58.12 

59.12 

60.88 

2025001 

0 

0 

#23 

SH60#0 

0 

4500 

59.33 

60.33 

64.08 

65.08 

67.12 

2020501 

0 

0 

#24 

SH60#1 

0 

4500 

60.83 

61.83 

65.58 

66.58 

68.62 

2016001 

0 

0 

#25 

CH53#0 

0 

27000 

60.88 

61.88 

64.88 

65.88 

67.65 

1989001 

0 

0 

#26 

SH60#0 

0 

4500 

67.12 

68.12 

71.87 

72.87 

74.91 

1984501 

0 

0 

#27 

SH60#1 

0 

4500 

68.62 

69.62 

73.37 

74.37 

76.41 

1980001 

0 

0 

#28 

CH53#0 

0 

27000 

67.65 

68.65 

71.65 

72.65 

74.41 

1953001 

0 

0 

#29 

SH60#0 

0 

4500 

74.91 

75.91 

79.66 

80.66 

82.7 

1948501 

0 

0 

#30 

CH53#0 

0 

27000 

74.41 

75.41 

78.41 

79.41 

81.18 

1921501 

0 

0 

#31 

SH60#1 

0 

4500 

76.41 

77.41 

81.16 

82.16 

84.2 

1917001 

0 

0 

#32 

CH53#0 

0 

27000 

81.18 

82.18 

85.18 

86.18 

87.94 

1890001 

0 

0 

#33 

SH60#0 

0 

4500 

82.7 

83.7 

87.45 

88.45 

90.49 

1885501 

0 

0 

#34 

SH60#1 

0 

4500 

84.2 

85.2 

88.95 

89.95 

91.99 

1881001 

0 

0 

#35 

CH53#0 

0 

27000 

87.94 

88.94 

91.94 

92.94 

94.71 

1854001 

0 

0 
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Assign# 

Aircraft# 

Load 

Type# 

Transfer 

Qty 

Start 

Loading 

Time 

Start 

Sortie 

Time 

Reach 

Target 

Time 

Leave 

Target 

Time 

End 

Sortie 

Time 

Cargo 

Left 

Eqpt 

Left 

Passenger 

Left 

#36 

SH60#0 

0 

4500 

90.49 

91.49 

95.24 

96.24 

98.28 

1849501 

0 

0 

#37 

SH60#1 

0 

4500 

91.99 

92.99 

96.74 

97.74 

99.78 

1845001 

0 

0 

#38 

CH53#0 

0 

27000 

94.71 

95.71 

98.71 

99.71 

101.47 

1818001 

0 

0 

#39 

SH60#0 

0 

4500 

98.28 

99.28 

103.03 

104.03 

106.07 

1813501 

0 

0 

#40 

SH60#1 

0 

4500 

99.78 

100.78 

104.53 

105.53 

107.57 

1809001 

0 

0 

#41 

CH53#0 

0 

27000 

101.47 

102.47 

105.47 

106.47 

108.24 

1782001 

0 

0 

#42 

SH60#0 

0 

4500 

106.07 

107.07 

110.82 

111.82 

113.86 

1777501 

0 

0 

#43 

SH60#1 

0 

4500 

107.57 

108.57 

112.32 

113.32 

115.36 

1773001 

0 

0 

#44 

CH53#0 

0 

27000 

108.24 

109.24 

112.24 

113.24 

115 

1746001 

0 

0 

#45 

SH60#0 

0 

4500 

113.86 

114.86 

118.61 

119.61 

121.65 

1741501 

0 

0 

#46 

SH60#1 

0 

4500 

115.36 

116.36 

120.11 

121.11 

123.15 

1737001 

0 

0 

#47 

CH53#0 

0 

27000 

115 

116 

119 

120 

121.76 

1710001 

0 

0 

#48 

SH60#0 

0 

4500 

121.65 

122.65 

126.4 

127.4 

129.44 

1705501 

0 

0 

#49 

CH53#0 

0 

27000 

121.76 

122.76 

125.76 

126.76 

128.53 

1678501 

0 

0 

#50 

SH60#1 

0 

4500 

123.15 

124.15 

127.9 

128.9 

130.94 

1674001 

0 

0 

#51 

SH60#0 

0 

4500 

129.44 

130.44 

134.19 

135.19 

137.23 

1669501 

0 

0 

#52 

CH53#0 

0 

27000 

128.53 

129.53 

132.53 

133.53 

135.29 

1642501 

0 

0 

#53 

SH60#1 

0 

4500 

130.94 

131.94 

135.69 

136.69 

138.73 

1638001 

0 

0 

#54 

CH53#0 

0 

27000 

135.29 

136.29 

139.29 

140.29 

142.06 

1611001 

0 

0 

#55 

SH60#0 

0 

4500 

137.23 

138.23 

141.98 

142.98 

145.03 

1606501 

0 

0 

#56 

SH60#1 

0 

4500 

138.73 

139.73 

143.48 

144.48 

146.53 

1602001 

0 

0 

#57 

CH53#0 

0 

27000 

142.06 

143.06 

146.06 

147.06 

148.82 

1575001 

0 

0 

#58 

SH60#0 

0 

4500 

145.03 

146.03 

149.78 

150.78 

152.82 

1570501 

0 

0 

#59 

SH60#1 

0 

4500 

146.53 

147.53 

151.28 

152.28 

154.32 

1566001 

0 

0 

#60 

CH53#0 

0 

27000 

148.82 

149.82 

152.82 

153.82 

155.59 

1539001 

0 

0 

#61 

SH60#0 

0 

4500 

152.82 

153.82 

157.57 

158.57 

160.61 

1534501 

0 

0 

#62 

SH60#1 

0 

4500 

154.32 

155.32 

159.07 

160.07 

162.11 

1530001 

0 

0 

#63 

CH53#0 

0 

27000 

155.59 

156.59 

159.59 

160.59 

162.35 

1503001 

0 

0 

#64 

SH60#0 

0 

4500 

160.61 

161.61 

165.36 

166.36 

168.4 

1498501 

0 

0 

#65 

SH60#1 

0 

4500 

162.11 

163.11 

166.86 

167.86 

169.9 

1494001 

0 

0 

#66 

CH53#0 

0 

27000 

162.35 

163.35 

166.35 

167.35 

169.12 

1467001 

0 

0 

#67 

SH60#0 

0 

4500 

168.4 

169.4 

173.15 

174.15 

176.19 

1462501 

0 

0 

#68 

SH60#1 

0 

4500 

169.9 

170.9 

174.65 

175.65 

177.69 

1458001 

0 

0 

#69 

CH53#0 

0 

27000 

169.12 

170.12 

173.12 

174.12 

175.88 

1431001 

0 

0 

#70 

SH60#0 

0 

4500 

176.19 

177.19 

180.94 

181.94 

183.98 

1426501 

0 

0 

#71 

CH53#0 

0 

27000 

175.88 

176.88 

179.88 

180.88 

182.65 

1399501 

0 

0 

#72 

SH60#1 

0 

4500 

177.69 

178.69 

182.44 

183.44 

185.48 

1395001 

0 

0 

#73 

CH53#0 

0 

27000 

182.65 

183.65 

186.65 

187.65 

189.41 

1368001 

0 

0 

#74 

SH60#0 

0 

4500 

183.98 

184.98 

188.73 

189.73 

191.77 

1363501 

0 

0 

#75 

SH60#1 

0 

4500 

185.48 

186.48 

190.23 

191.23 

193.27 

1359001 

0 

0 

#76 

CH53#0 

0 

27000 

189.41 

190.41 

193.41 

194.41 

196.18 

1332001 

0 

0 

#77 

SH60#0 

0 

4500 

191.77 

192.77 

196.52 

197.52 

199.56 

1327501 

0 

0 

#78 

SH60#1 

0 

4500 

193.27 

194.27 

198.02 

199.02 

201.06 

1323001 

0 

0 

#79 

CH53#0 

0 

27000 

196.18 

197.18 

200.18 

201.18 

202.94 

1296001 

0 

0 

#80 

SH60#0 

0 

4500 

199.56 

200.56 

204.31 

205.31 

207.35 

1291501 

0 

0 

#81 

SH60#1 

0 

4500 

201.06 

202.06 

205.81 

206.81 

208.85 

1287001 

0 

0 

#82 

CH53#0 

0 

27000 

202.94 

203.94 

206.94 

207.94 

209.71 

1260001 

0 

0 

#83 

SH60#0 

0 

4500 

207.35 

208.35 

212.1 

213.1 

215.14 

1255501 

0 

0 

#84 

SH60#1 

0 

4500 

208.85 

209.85 

213.6 

214.6 

216.64 

1251001 

0 

0 

#85 

CH53#0 

0 

27000 

209.71 

210.71 

213.71 

214.71 

216.47 

1224001 

0 

0 
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Assign# 

Aircraft# 

Load 

Type# 

Transfer 

Qty 

Start 

Loading 

Time 

Start 

Sortie 

Time 

Reach 

Target 

Time 

Leave 

Target 

Time 

End 

Sortie 

Time 

Cargo 

Left 

Eqpt 

Left 

Passenger 

Left 

#86 

SH60#0 

0 

4500 

215.14 

216.14 

219.89 

220.89 

222.93 

1219501 

0 

0 

#87 

SH60#1 

0 

4500 

216.64 

217.64 

221.39 

222.39 

224.43 

1215001 

0 

0 

#88 

CH53#0 

0 

27000 

216.47 

217.47 

220.47 

221.47 

223.24 

1188001 

0 

0 

#89 

SH60#0 

0 

4500 

222.93 

223.93 

227.68 

228.68 

230.72 

1183501 

0 

0 

#90 

CH53#0 

0 

27000 

223.24 

224.24 

227.24 

228.24 

230 

1156501 

0 

0 

#91 

SH60#1 

0 

4500 

224.43 

225.43 

229.18 

230.18 

232.22 

1152001 

0 

0 

#92 

SH60#0 

0 

4500 

230.72 

231.72 

235.47 

236.47 

238.52 

1147501 

0 

0 

#93 

CH53#0 

0 

27000 

230 

231 

234 

235 

236.76 

1120501 

0 

0 

#94 

SH60#1 

0 

4500 

232.22 

233.22 

236.97 

237.97 

240.02 

1116001 

0 

0 

#95 

CH53#0 

0 

27000 

236.76 

237.76 

240.76 

241.76 

243.53 

1089001 

0 

0 

#96 

SH60#0 

0 

4500 

238.52 

239.52 

243.27 

244.27 

246.31 

1084501 

0 

0 

#97 

SH60#1 

0 

4500 

240.02 

241.02 

244.77 

245.77 

247.81 

1080001 

0 

0 

#98 

CH53#0 

0 

27000 

243.53 

244.53 

247.53 

248.53 

250.29 

1053001 

0 

0 

#99 

SH60#0 

0 

4500 

246.31 

247.31 

251.06 

252.06 

254.1 

1048501 

0 

0 

#100 

SH60#1 

0 

4500 

247.81 

248.81 

252.56 

253.56 

255.6 

1044001 

0 

0 

#101 

CH53#0 

0 

27000 

250.29 

251.29 

254.29 

255.29 

257.06 

1017001 

0 

0 

#102 

SH60#0 

0 

4500 

254.1 

255.1 

258.85 

259.85 

261.89 

1012501 

0 

0 

#103 

SH60#1 

0 

4500 

255.6 

256.6 

260.35 

261.35 

263.39 

1008001 

0 

0 

#104 

CH53#0 

0 

27000 

257.06 

258.06 

261.06 

262.06 

263.82 

981001 

0 

0 

#105 

SH60#0 

0 

4500 

261.89 

262.89 

266.64 

267.64 

269.68 

976501 

0 

0 

#106 

SH60#1 

0 

4500 

263.39 

264.39 

268.14 

269.14 

271.18 

972001 

0 

0 

#107 

CH53#0 

0 

27000 

263.82 

264.82 

267.82 

268.82 

270.59 

945001 

0 

0 

#108 

SH60#0 

0 

4500 

269.68 

270.68 

274.43 

275.43 

277.47 

940501 

0 

0 

#109 

SH60#1 

0 

4500 

271.18 

272.18 

275.93 

276.93 

278.97 

936001 

0 

0 

#110 

CH53#0 

0 

27000 

270.59 

271.59 

274.59 

275.59 

277.35 

909001 

0 

0 

#111 

SH60#0 

0 

4500 

277.47 

278.47 

282.22 

283.22 

285.26 

904501 

0 

0 

#112 

CH53#0 

0 

27000 

277.35 

278.35 

281.35 

282.35 

284.12 

877501 

0 

0 

#113 

SH60#1 

0 

4500 

278.97 

279.97 

283.72 

284.72 

286.76 

873001 

0 

0 

#114 

CH53#0 

0 

27000 

284.12 

285.12 

288.12 

289.12 

290.88 

846001 

0 

0 

#115 

SH60#0 

0 

4500 

285.26 

286.26 

290.01 

291.01 

293.05 

841501 

0 

0 

#116 

SH60#1 

0 

4500 

286.76 

287.76 

291.51 

292.51 

294.55 

837001 

0 

0 

#117 

CH53#0 

0 

27000 

290.88 

291.88 

294.88 

295.88 

297.65 

810001 

0 

0 

#118 

SH60#0 

0 

4500 

293.05 

294.05 

297.8 

298.8 

300.84 

805501 

0 

0 

#119 

SH60#1 

0 

4500 

294.55 

295.55 

299.3 

300.3 

302.34 

801001 

0 

0 

#120 

CH53#0 

0 

27000 

297.65 

298.65 

301.65 

302.65 

304.41 

774001 

0 

0 

#121 

SH60#0 

0 

4500 

300.84 

301.84 

305.59 

306.59 

308.63 

769501 

0 

0 

#122 

SH60#1 

0 

4500 

302.34 

303.34 

307.09 

308.09 

310.13 

765001 

0 

0 

#123 

CH53#0 

0 

27000 

304.41 

305.41 

308.41 

309.41 

311.18 

738001 

0 

0 

#124 

SH60#0 

0 

4500 

308.63 

309.63 

313.38 

314.38 

316.42 

733501 

0 

0 

#125 

SH60#1 

0 

4500 

310.13 

311.13 

314.88 

315.88 

317.92 

729001 

0 

0 

#126 

CH53#0 

0 

27000 

311.18 

312.18 

315.18 

316.18 

317.94 

702001 

0 

0 

#127 

SH60#0 

0 

4500 

316.42 

317.42 

321.17 

322.17 

324.21 

697501 

0 

0 

#128 

SH60#1 

0 

4500 

317.92 

318.92 

322.67 

323.67 

325.71 

693001 

0 

0 

#129 

CH53#0 

0 

27000 

317.94 

318.94 

321.94 

322.94 

324.71 

666001 

0 

0 

#130 

SH60#0 

0 

4500 

324.21 

325.21 

328.96 

329.96 

332.01 

661501 

0 

0 

#131 

SH60#1 

0 

4500 

325.71 

326.71 

330.46 

331.46 

333.51 

657001 

0 

0 

#132 

CH53#0 

0 

27000 

324.71 

325.71 

328.71 

329.71 

331.47 

630001 

0 

0 

#133 

SH60#0 

0 

4500 

332.01 

333.01 

336.76 

337.76 

339.8 

625501 

0 

0 

#134 

CH53#0 

0 

27000 

331.47 

332.47 

335.47 

336.47 

338.24 

598501 

0 

0 

#135 

SH60#1 

0 

4500 

333.51 

334.51 

338.26 

339.26 

341.3 

594001 

0 

0 
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Assign# 

Aircraft# 

Load 

Type# 

Transfer 

Qty 

Start 

Loading 

Time 

Start 

Sortie 

Time 

Reach 

Target 

Time 

Leave 

Target 

Time 

End 

Sortie 

Time 

Cargo 

Left 

Eqpt 

Left 

Passenger 

Left 

#136 

CH53#0 

0 

27000 

338.24 

339.24 

342.24 

343.24 

345 

567001 

0 

0 

#137 

SH60#0 

0 

4500 

339.8 

340.8 

344.55 

345.55 

347.59 

562501 

0 

0 

#138 

SH60#1 

0 

4500 

341.3 

342.3 

346.05 

347.05 

349.09 

558001 

0 

0 

#139 

CH53#0 

0 

27000 

345 

346 

349 

350 

351.76 

531001 

0 

0 

#140 

SH60#0 

0 

4500 

347.59 

348.59 

352.34 

353.34 

355.38 

526501 

0 

0 

#141 

SH60#1 

0 

4500 

349.09 

350.09 

353.84 

354.84 

356.88 

522001 

0 

0 

#142 

CH53#0 

0 

27000 

351.76 

352.76 

355.76 

356.76 

358.53 

495001 

0 

0 

#143 

SH60#0 

0 

4500 

355.38 

356.38 

360.13 

361.13 

363.17 

490501 

0 

0 

#144 

SH60#1 

0 

4500 

356.88 

357.88 

361.63 

362.63 

364.67 

486001 

0 

0 

#145 

CH53#0 

0 

27000 

358.53 

359.53 

362.53 

363.53 

365.29 

459001 

0 

0 

#146 

SH60#0 

0 

4500 

363.17 

364.17 

367.92 

368.92 

370.96 

454501 

0 

0 

#147 

SH60#1 

0 

4500 

364.67 

365.67 

369.42 

370.42 

372.46 

450001 

0 

0 

#148 

CH53#0 

0 

27000 

365.29 

366.29 

369.29 

370.29 

372.06 

423001 

0 

0 

#149 

SH60#0 

0 

4500 

370.96 

371.96 

375.71 

376.71 

378.75 

418501 

0 

0 

#150 

SH60#1 

0 

4500 

372.46 

373.46 

377.21 

378.21 

380.25 

414001 

0 

0 

#151 

CH53#0 

0 

27000 

372.06 

373.06 

376.06 

377.06 

378.82 

387001 

0 

0 

#152 

SH60#0 

0 

4500 

378.75 

379.75 

383.5 

384.5 

386.54 

382501 

0 

0 

#153 

CH53#0 

0 

27000 

378.82 

379.82 

382.82 

383.82 

385.59 

355501 

0 

0 

#154 

SH60#1 

0 

4500 

380.25 

381.25 

385 

386 

388.04 

351001 

0 

0 

#155 

SH60#0 

0 

4500 

386.54 

387.54 

391.29 

392.29 

394.33 

346501 

0 

0 

#156 

CH53#0 

0 

27000 

385.59 

386.59 

389.59 

390.59 

392.35 

319501 

0 

0 

#157 

SH60#1 

0 

4500 

388.04 

389.04 

392.79 

393.79 

395.83 

315001 

0 

0 

#158 

CH53#0 

0 

27000 

392.35 

393.35 

396.35 

397.35 

399.12 

288001 

0 

0 

#159 

SH60#0 

0 

4500 

394.33 

395.33 

399.08 

400.08 

402.12 

283501 

0 

0 

#160 

SH60#1 

0 

4500 

395.83 

396.83 

400.58 

401.58 

403.62 

279001 

0 

0 

#161 

CH53#0 

0 

27000 

399.12 

400.12 

403.12 

404.12 

405.88 

252001 

0 

0 

#162 

SH60#0 

0 

4500 

402.12 

403.12 

406.87 

407.87 

409.91 

247501 

0 

0 

#163 

SH60#1 

0 

4500 

403.62 

404.62 

408.37 

409.37 

411.41 

243001 

0 

0 

#164 

CH53#0 

0 

27000 

405.88 

406.88 

409.88 

410.88 

412.65 

216001 

0 

0 

#165 

SH60#0 

0 

4500 

409.91 

410.91 

414.66 

415.66 

417.7 

211501 

0 

0 

#166 

SH60#1 

0 

4500 

411.41 

412.41 

416.16 

417.16 

419.2 

207001 

0 

0 

#167 

CH53#0 

0 

27000 

412.65 

413.65 

416.65 

417.65 

419.41 

180001 

0 

0 

#168 

SH60#0 

0 

4500 

417.7 

418.7 

422.45 

423.45 

425.49 

175501 

0 

0 

#169 

SH60#1 

0 

4500 

419.2 

420.2 

423.95 

424.95 

426.99 

171001 

0 

0 

#170 

CH53#0 

0 

27000 

419.41 

420.41 

423.41 

424.41 

426.18 

144001 

0 

0 

#171 

SH60#0 

0 

4500 

425.49 

426.49 

430.24 

431.24 

433.29 

139501 

0 

0 

#172 

SH60#1 

0 

4500 

426.99 

427.99 

431.74 

432.74 

434.79 

135001 

0 

0 

#173 

CH53#0 

0 

27000 

426.18 

427.18 

430.18 

431.18 

432.94 

108001 

0 

0 

#174 

SH60#0 

0 

4500 

433.29 

434.29 

438.04 

439.04 

441.08 

103501 

0 

0 

#175 

CH53#0 

0 

27000 

432.94 

433.94 

436.94 

437.94 

439.71 

76501 

0 

0 

#176 

SH60#1 

0 

4500 

434.79 

435.79 

439.54 

440.54 

442.58 

72001 

0 

0 

#177 

CH53#0 

0 

27000 

439.71 

440.71 

443.71 

444.71 

446.47 

45001 

0 

0 

#178 

SH60#0 

0 

4500 

441.08 

442.08 

445.83 

446.83 

448.87 

40501 

0 

0 

#179 

SH60#1 

0 

4500 

442.58 

443.58 

447.33 

448.33 

450.37 

36001 

0 

0 

#180 

CH53#0 

0 

27000 

446.47 

447.47 

450.47 

451.47 

453.24 

9001 

0 

0 

#181 

SH60#0 

0 

4500 

448.87 

449.87 

453.62 

454.62 

456.66 

4501 

0 

0 

#182 

SH60#1 

0 

4500 

450.37 

451.37 

455.12 

456.12 

458.16 

1 

0 

0 

#183 

CH53#0 

0 

1 

453.24 

454.24 

457.24 

458.24 

460 

0 

0 

0 


Table 41. Final Airlift Model Output for Low Severity Scenario Test Case 
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B. MODEL OUTPUT FROM MEAN SEVERITY SCENARIO TEST CASE 


Assign# 

Aircraft# 

Load 

Type# 

Transfer 

Qty 

Start 

Loading 

Time 

Start 

Sortie 

Time 

Reach 

Target 

Time 

Leave 

Target 

Time 

End 

Sortie 

Time 

Cargo 

Left 

Eqpt 

Left 

Passenger 

Left 

#1 

CH53#0 

1 

2 

0 

1 

19 

20 

30.59 

729001 

9 

72 

#2 

CH53#1 

1 

2 

0 

1 

19 

20 

30.59 

729001 

7 

72 

#3 

SH60#0 

2 

12 

0 

5 

17.26 

22.26 

34.51 

729001 

7 

60 

#4 

SH60#1 

2 

12 

0 

5 

17.26 

22.26 

34.51 

729001 

7 

48 

#5 

CH53#0 

1 

2 

30.59 

31.59 

49.59 

50.59 

61.18 

729001 

5 

48 

#6 

CH53#1 

1 

2 

30.59 

31.59 

49.59 

50.59 

61.18 

729001 

3 

48 

#7 

SH60#0 

2 

12 

34.51 

39.51 

51.77 

56.77 

69.03 

729001 

3 

36 

#8 

SH60#1 

2 

12 

34.51 

39.51 

51.77 

56.77 

69.03 

729001 

3 

24 

#9 

CH53#0 

1 

2 

61.18 

62.18 

80.18 

81.18 

91.76 

729001 

1 

24 

#10 

CH53#1 

1 

1 

61.18 

62.18 

80.18 

81.18 

91.76 

729001 

0 

24 

#11 

SH60#0 

2 

12 

69.03 

74.03 

86.29 

91.29 

103.54 

729001 

0 

12 

#12 

SH60#1 

2 

12 

69.03 

74.03 

86.29 

91.29 

103.54 

729001 

0 

0 

#13 

CH53#0 

0 

27000 

91.76 

92.76 

110.76 

111.76 

122.35 

702001 

0 

0 

#14 

CH53#1 

0 

27000 

91.76 

92.76 

110.76 

111.76 

122.35 

675001 

0 

0 

#15 

SH60#0 

0 

4500 

103.54 

104.54 

127.07 

128.07 

140.32 

670501 

0 

0 

#16 

SH60#1 

0 

4500 

103.54 

104.54 

127.07 

128.07 

140.32 

666001 

0 

0 

#17 

CH53#0 

0 

27000 

122.35 

123.35 

141.35 

142.35 

152.94 

639001 

0 

0 

#18 

CH53#1 

0 

27000 

122.35 

123.35 

141.35 

142.35 

152.94 

612001 

0 

0 

#19 

SH60#0 

0 

4500 

140.32 

141.32 

163.84 

164.84 

177.1 

607501 

0 

0 

#20 

SH60#1 

0 

4500 

140.32 

141.32 

163.84 

164.84 

177.1 

603001 

0 

0 

#21 

CH53#0 

0 

27000 

152.94 

153.94 

171.94 

172.94 

183.53 

576001 

0 

0 

#22 

CH53#1 

0 

27000 

152.94 

153.94 

171.94 

172.94 

183.53 

549001 

0 

0 

#23 

SH60#0 

0 

4500 

177.1 

178.1 

200.62 

201.62 

213.88 

544501 

0 

0 

#24 

SH60#1 

0 

4500 

177.1 

178.1 

200.62 

201.62 

213.88 

540001 

0 

0 

#25 

CH53#0 

0 

27000 

183.53 

184.53 

202.53 

203.53 

214.12 

513001 

0 

0 

#26 

CH53#1 

0 

27000 

183.53 

184.53 

202.53 

203.53 

214.12 

486001 

0 

0 

#27 

SH60#0 

0 

4500 

213.88 

214.88 

237.4 

238.4 

250.66 

481501 

0 

0 

#28 

SH60#1 

0 

4500 

213.88 

214.88 

237.4 

238.4 

250.66 

477001 

0 

0 

#29 

CH53#0 

0 

27000 

214.12 

215.12 

233.12 

234.12 

244.71 

450001 

0 

0 

#30 

CH53#1 

0 

27000 

214.12 

215.12 

233.12 

234.12 

244.71 

423001 

0 

0 

#31 

SH60#0 

0 

4500 

250.66 

251.66 

274.18 

275.18 

287.44 

418501 

0 

0 

#32 

SH60#1 

0 

4500 

250.66 

251.66 

274.18 

275.18 

287.44 

414001 

0 

0 

#33 

CH53#0 

0 

27000 

244.71 

245.71 

263.71 

264.71 

275.29 

387001 

0 

0 

#34 

CH53#1 

0 

27000 

244.71 

245.71 

263.71 

264.71 

275.29 

360001 

0 

0 

#35 

CH53#0 

0 

27000 

275.29 

276.29 

294.29 

295.29 

305.88 

333001 

0 

0 

#36 

CH53#1 

0 

27000 

275.29 

276.29 

294.29 

295.29 

305.88 

306001 

0 

0 

#37 

SH60#0 

0 

4500 

287.44 

288.44 

310.96 

311.96 

324.22 

301501 

0 

0 

#38 

SH60#1 

0 

4500 

287.44 

288.44 

310.96 

311.96 

324.22 

297001 

0 

0 

#39 

CH53#0 

0 

27000 

305.88 

306.88 

324.88 

325.88 

336.47 

270001 

0 

0 

#40 

CH53#1 

0 

27000 

305.88 

306.88 

324.88 

325.88 

336.47 

243001 

0 

0 

#41 

SH60#0 

0 

4500 

324.22 

325.22 

347.74 

348.74 

361 

238501 

0 

0 

#42 

SH60#1 

0 

4500 

324.22 

325.22 

347.74 

348.74 

361 

234001 

0 

0 

#43 

CH53#0 

0 

27000 

336.47 

337.47 

355.47 

356.47 

367.06 

207001 

0 

0 

#44 

CH53#1 

0 

27000 

336.47 

337.47 

355.47 

356.47 

367.06 

180001 

0 

0 

#45 

SH60#0 

0 

4500 

361 

362 

384.52 

385.52 

397.78 

175501 

0 

0 

#46 

SH60#1 

0 

4500 

361 

362 

384.52 

385.52 

397.78 

171001 

0 

0 

#47 

CH53#0 

0 

27000 

367.06 

368.06 

386.06 

387.06 

397.65 

144001 

0 

0 

#48 

CH53#1 

0 

27000 

367.06 

368.06 

386.06 

387.06 

397.65 

117001 

0 

0 
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Assign# 

Aircraft# 

Load 

Type# 

Transfer 

Qty 

Start 

Loading 

Time 

Start 

Sortie 

Time 

Reach 

Target 

Time 

Leave 

Target 

Time 

End 

Sortie 

Time 

Cargo 

Left 

Eqpt 

Left 

Passenger 

Left 

#49 

SH60#0 

0 

4500 

397.78 

398.78 

421.3 

422.3 

434.56 

112501 

0 

0 

#50 

SH60#1 

0 

4500 

397.78 

398.78 

421.3 

422.3 

434.56 

108001 

0 

0 

#51 

CH53#0 

0 

27000 

397.65 

398.65 

416.65 

417.65 

428.24 

81001 

0 

0 

#52 

CH53#1 

0 

27000 

397.65 

398.65 

416.65 

417.65 

428.24 

54001 

0 

0 

#53 

CH53#0 

0 

27000 

428.24 

429.24 

447.24 

448.24 

458.82 

27001 

0 

0 

#54 

CH53#1 

0 

27000 

428.24 

429.24 

447.24 

448.24 

458.82 

1 

0 

0 

#55 

SH60#0 

0 

1 

434.56 

435.56 

458.08 

459.08 

471.34 

0 

0 

0 


Table 42. Final Airlift Model Output for Mean Severity Seenario Test Case 


C. MODEL OUTPUT FROM HIGH SEVERITY SCENARIO TEST CASE 


Assign# 

Aircraft# 

Load 

Type# 

Transfer 

Qty 

Start 

Loading 

Time 

Start 

Sortie 

Time 

Reach 

Target 

Time 

Leave 

Target 

Time 

End 

Sortie 

Time 

Cargo 

Left 

Eqpt 

Left 

Passenger 

Left 

#1 

CH53#0 

1 

2 

0 

1 

34 

35 

54.41 

1318501 

14 

99 

#2 

CH53#1 

1 

2 

0 

1 

34 

35 

54.41 

1318501 

12 

99 

#3 

CH53#2 

1 

2 

0 

1 

34 

35 

54.41 

1318501 

10 

99 

#4 

CH53#3 

1 

2 

0 

1 

34 

35 

54.41 

1318501 

8 

99 

#5 

CH53#4 

1 

2 

0 

1 

34 

35 

54.41 

1318501 

6 

99 

#6 

CH53#5 

1 

2 

0 

1 

34 

35 

54.41 

1318501 

4 

99 

#7 

CH53#6 

1 

2 

0 

1 

34 

35 

54.41 

1318501 

2 

99 

#8 

SH60#0 

2 

12 

0 

5 

27.45 

32.45 

54.9 

1318501 

2 

87 

#9 

SH60#1 

2 

12 

0 

5 

27.45 

32.45 

54.9 

1318501 

2 

75 

#10 

CH53#0 

1 

2 

54.41 

55.41 

88.41 

89.41 

108.82 

1318501 

0 

75 

#11 

CH53#1 

0 

27000 

54.41 

55.41 

88.41 

89.41 

108.82 

1291501 

0 

75 

#12 

CH53#2 

0 

27000 

54.41 

55.41 

88.41 

89.41 

108.82 

1264501 

0 

75 

#13 

CH53#3 

0 

27000 

54.41 

55.41 

88.41 

89.41 

108.82 

1237501 

0 

75 

#14 

CH53#4 

0 

27000 

54.41 

55.41 

88.41 

89.41 

108.82 

1210501 

0 

75 

#15 

CH53#5 

0 

27000 

54.41 

55.41 

88.41 

89.41 

108.82 

1183501 

0 

75 

#16 

CH53#6 

0 

27000 

54.41 

55.41 

88.41 

89.41 

108.82 

1156501 

0 

75 

#17 

SH60#0 

2 

12 

54.9 

59.9 

82.35 

87.35 

109.8 

1156501 

0 

63 

#18 

SH60#1 

2 

12 

54.9 

59.9 

82.35 

87.35 

109.8 

1156501 

0 

51 

#19 

CH53#0 

0 

27000 

108.82 

109.82 

142.82 

143.82 

163.24 

1129501 

0 

51 

#20 

CH53#1 

0 

27000 

108.82 

109.82 

142.82 

143.82 

163.24 

1102501 

0 

51 

#21 

CH53#2 

0 

27000 

108.82 

109.82 

142.82 

143.82 

163.24 

1075501 

0 

51 

#22 

CH53#3 

0 

27000 

108.82 

109.82 

142.82 

143.82 

163.24 

1048501 

0 

51 

#23 

CH53#4 

0 

27000 

108.82 

109.82 

142.82 

143.82 

163.24 

1021501 

0 

51 

#24 

CH53#5 

0 

27000 

108.82 

109.82 

142.82 

143.82 

163.24 

994501 

0 

51 

#25 

CH53#6 

0 

27000 

108.82 

109.82 

142.82 

143.82 

163.24 

967501 

0 

51 

#26 

SH60#0 

2 

12 

109.8 

114.8 

137.24 

142.24 

164.69 

967501 

0 

39 

#27 

SH60#1 

2 

12 

109.8 

114.8 

137.24 

142.24 

164.69 

967501 

0 

27 

#28 

CH53#0 

0 

27000 

163.24 

164.24 

197.24 

198.24 

217.65 

940501 

0 

27 

#29 

CH53#1 

0 

27000 

163.24 

164.24 

197.24 

198.24 

217.65 

913501 

0 

27 

#30 

CH53#2 

0 

27000 

163.24 

164.24 

197.24 

198.24 

217.65 

886501 

0 

27 

#31 

CH53#3 

0 

27000 

163.24 

164.24 

197.24 

198.24 

217.65 

859501 

0 

27 

#32 

CH53#4 

0 

27000 

163.24 

164.24 

197.24 

198.24 

217.65 

832501 

0 

27 

#33 

CH53#5 

0 

27000 

163.24 

164.24 

197.24 

198.24 

217.65 

805501 

0 

27 

#34 

CH53#6 

0 

27000 

163.24 

164.24 

197.24 

198.24 

217.65 

778501 

0 

27 

#35 

SH60#0 

2 

12 

164.69 

169.69 

192.14 

197.14 

219.59 

778501 

0 

15 
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Assign# 

Aircraft# 

Load 

Type# 

Transfer 

Qty 

Start 

Loading 

Time 

Start 

Sortie 

Time 

Reach 

Target 

Time 

Leave 

Target 

Time 

End 

Sortie 

Time 

Cargo 

Left 

Eqpt 

Left 

Passenger 

Left 

#36 

SH60#1 

2 

12 

164.69 

169.69 

192.14 

197.14 

219.59 

778501 

0 

3 

#37 

CH53#0 

0 

27000 

217.65 

218.65 

251.65 

252.65 

272.06 

751501 

0 

3 

#38 

CH53#1 

0 

27000 

217.65 

218.65 

251.65 

252.65 

272.06 

724501 

0 

3 

#39 

CH53#2 

0 

27000 

217.65 

218.65 

251.65 

252.65 

272.06 

697501 

0 

3 

#40 

CH53#3 

0 

27000 

217.65 

218.65 

251.65 

252.65 

272.06 

670501 

0 

3 

#41 

CH53#4 

0 

27000 

217.65 

218.65 

251.65 

252.65 

272.06 

643501 

0 

3 

#42 

CH53#5 

0 

27000 

217.65 

218.65 

251.65 

252.65 

272.06 

616501 

0 

3 

#43 

CH53#6 

0 

27000 

217.65 

218.65 

251.65 

252.65 

272.06 

589501 

0 

3 

#44 

SH60#0 

2 

3 

219.59 

224.59 

247.04 

252.04 

274.49 

589501 

0 

0 

#45 

SH60#1 

0 

4500 

219.59 

220.59 

261.84 

262.84 

285.29 

585001 

0 

0 

#46 

CH53#0 

0 

27000 

272.06 

273.06 

306.06 

307.06 

326.47 

558001 

0 

0 

#47 

CH53#1 

0 

27000 

272.06 

273.06 

306.06 

307.06 

326.47 

531001 

0 

0 

#48 

CH53#2 

0 

27000 

272.06 

273.06 

306.06 

307.06 

326.47 

504001 

0 

0 

#49 

CH53#3 

0 

27000 

272.06 

273.06 

306.06 

307.06 

326.47 

477001 

0 

0 

#50 

CH53#4 

0 

27000 

272.06 

273.06 

306.06 

307.06 

326.47 

450001 

0 

0 

#51 

CH53#5 

0 

27000 

272.06 

273.06 

306.06 

307.06 

326.47 

423001 

0 

0 

#52 

CH53#6 

0 

27000 

272.06 

273.06 

306.06 

307.06 

326.47 

396001 

0 

0 

#53 

SH60#1 

0 

4500 

285.29 

286.29 

327.54 

328.54 

350.99 

391501 

0 

0 

#54 

SH60#0 

0 

4500 

274.49 

275.49 

316.74 

317.74 

340.19 

387001 

0 

0 

#55 

CH53#0 

0 

27000 

326.47 

327.47 

360.47 

361.47 

380.88 

360001 

0 

0 

#56 

CH53#1 

0 

27000 

326.47 

327.47 

360.47 

361.47 

380.88 

333001 

0 

0 

#57 

CH53#2 

0 

27000 

326.47 

327.47 

360.47 

361.47 

380.88 

306001 

0 

0 

#58 

CH53#3 

0 

27000 

326.47 

327.47 

360.47 

361.47 

380.88 

279001 

0 

0 

#59 

CH53#4 

0 

27000 

326.47 

327.47 

360.47 

361.47 

380.88 

252001 

0 

0 

#60 

CH53#5 

0 

27000 

326.47 

327.47 

360.47 

361.47 

380.88 

225001 

0 

0 

#61 

CH53#6 

0 

27000 

326.47 

327.47 

360.47 

361.47 

380.88 

198001 

0 

0 

#62 

SH60#0 

0 

4500 

340.19 

341.19 

382.44 

383.44 

405.89 

193501 

0 

0 

#63 

SH60#1 

0 

4500 

350.99 

351.99 

393.24 

394.24 

416.69 

189001 

0 

0 

#64 

CH53#0 

0 

27000 

380.88 

381.88 

414.88 

415.88 

435.29 

162001 

0 

0 

#65 

CH53#1 

0 

27000 

380.88 

381.88 

414.88 

415.88 

435.29 

135001 

0 

0 

#66 

CH53#2 

0 

27000 

380.88 

381.88 

414.88 

415.88 

435.29 

108001 

0 

0 

#67 

CH53#3 

0 

27000 

380.88 

381.88 

414.88 

415.88 

435.29 

81001 

0 

0 

#68 

CH53#4 

0 

27000 

380.88 

381.88 

414.88 

415.88 

435.29 

54001 

0 

0 

#69 

CH53#5 

0 

27000 

380.88 

381.88 

414.88 

415.88 

435.29 

27001 

0 

0 

#70 

CH53#6 

0 

27000 

380.88 

381.88 

414.88 

415.88 

435.29 

1 

0 

0 

#71 

SH60#0 

0 

1 

405.89 

406.89 

448.14 

449.14 

471.59 

0 

0 

0 


Table 43. Final Airlift Model Output for High Severity Seenario Test Case 
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APPENDIX C. INPUT PARAMETERS EOR EXPERIMENT #I 



Table 44. Input Parameters for Experiment #1 
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Table 45. Input Parameters for Experiment #1 (Continued) 
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Table 46. Input Parameters for Experiment #1 (Continued) 
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Table 47. Input Parameters for Experiment #1 (Continued) 
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Table 48. Input Parameters for Experiment #1 (Continued) 
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Table 49. Input Parameters for Experiment #1 (Continued) 
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